CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification
Overview
Design patterns in software engineering is a time-tested reusable solution to recurring problems in software design. The origin of design patterns can be owed to the work of civil engineer Christopher Alexander, who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.
Schemes for Pattern Classification
Gang of Four's Classification
Design Patterns gained popularity with the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
- What does the pattern do?
- Structural - These patterns deal with the composition of classes and their object.
- Creational - These patterns deal with object creation.
- Behavioral - These patterns deal with the interaction between classes and object and how they delegate responsibility.
- What is the scope of the pattern?
- Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
- Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.
| Purpose | ||||
| Scope | Creational | Structural | Behavioral | |
| Class | Factory Method | Adapter (class) | Interpreter | |
| Template Method | ||||
| Object | Abstract Factory | Adapter (object) | Command | |
| Prototype | Composite | Mediator | ||
| Builder | Bridge | Iterator | ||
| Singleton | Decorator | Memento | ||
| Facade | Observer | |||
| Flyweight | State | |||
| Proxy | Strategy | |||
| Visitor | ||||
| Chain Of Responsibility | ||||
Zimmer's Classification
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
- X uses Y in its solution.
- The Interpreter design pattern uses the Composite design patter.
- The Prototype design pattern uses the Singleton design pattern.
- Variant of X uses Y in its solution.
- X is similar to Y.
Using these relationships Zimmer placed design pattern in 3 layers.
| Layer | Design Pattern |
| Basic design patterns and techniques. | Singleton, Template Method, Mediator, Facade, Memento, Iterator, Flyweight. |
| Design patterns for typical software problems. | Abstract Factory, Builder, Strategy, Observer, Bridge, Adapter, Prototype, Factory Method, State, Command, Visitor, Composite, Decorator, Chain Of Responsibility, Proxy |
| Design patterns specific to an application domain. | Interpreter |
Coad's Classification
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
- Fundamental Pattern: This pattern is the template that all the other patterns follow.
- Collection-Worker Pattern is the fundamental object model pattern.
- Transaction Patterns: These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
- Actor-Participant pattern.
- Participant-Transaction pattern.
- Place-Transaction pattern.
- Specific Item-Transaction pattern.
- Transaction-Transaction Line Item pattern.
- Transaction-Subsequent Transaction pattern.
- Transaction Line Item-Subsequent Transaction Line Item pattern.
- Item-Line Item pattern.
- Specific Item-Line Item.
- Item-Specific Item.
- Associate-Other Associate.
- Specific Item-Hierarchical Item.
- Aggregate Patterns: These patterns interconnect with other patterns. The aggregate patterns are:
- Container-Content pattern.
- Container-Container Line Item pattern.
- Group-Member.
- Assembly-Part pattern.
- Compound Part-Part pattern.
- Packet-Packet Component.
- Plan Patterns: The plan patterns are:
- Plan-Step pattern.
- Plan-Plan Execution pattern.
- Plan Execution-Step Execution pattern.
- Step-Step Execution pattern.
- Plan-Plan Version pattern.
- Interaction Patterns: These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
- Peer-Peer pattern.
- Proxy-Specific Item pattern.
- Publisher-Subscriber pattern.
- Sender-Pass Through-Receiver pattern.
- Sender-Lookup-Receiver pattern.
- Caller-Dispatcher-Caller Back pattern.
- Gatekeeper-Request-Resource pattern.
Pree's Classification
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
- Basic inheritance and interaction patterns: These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
- Patterns for structuring object-oriented software systems: Most of Coad's patterns belong to this category.
- Patterns related to the MVC framework: Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
- Patterns relying on abstract coupling: Most of the patterns in the catalog are based on abstractly coupled classes. Factory Method pattern and Observer pattern for example.
- Patterns based on recursive structures: Composite pattern, Chain Of Responsibility pattern, Decorator pattern are all based on recursive structures.
- Other Catalog patterns: Pree summarized the rest of the patterns as follows:
- An Abstract Factory pattern is close to the Factory Method pattern
- Flyweight pattern represents a pattern similar to Coad's Item-Description pattern.
- Singleton pattern is a coding patterns that limits the number of creatable instances of a class to one.
- Template Method pattern forms the basis of all patterns dealing with with abstract classes.
Buschman et. al's Classification
Frank Buschman and Regine Meunier identified the following categories[6]:
- Granularity: Three levels of granularity can be specified.
- Architectural Framework: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The Model-View-Controller framework.
- Design Patterns: These can be described as the smaller architectural units.
- Idioms: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: The Counted Body Idiom.
- Functionality: Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
- Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: Singleton pattern
- Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
- Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: Proxy pattern
- Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: Command pattern
- Structural Principles: To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
- Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: Facade pattern
- Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: Mediator pattern
- Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
- Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: Bridge pattern
This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.
Tichy's Classification
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
- Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
- Modules(Encapsulation/Information Hiding)[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
- Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
- Repository pattern[8].
- Iterator pattern.
- Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
- Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
- Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
- Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
- Variant Management: treating different objects uniformly by factoring out their commonality.
- Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
- Visitor: Add new variations of operations to stable class hierarchy.
- Template Method: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
- Abstract Factory: Bundle the constructors of a family of related objects into one object.
- State Handling: generic manipulation of object state.
- Control: control of execution and method selection.
- Blackboard: Dynamically decide which transformers (knowledge sources) to apply to a shared data structure.
- Command: Separate composition of a request from the time it is executed.
- [Chain of Responsibility]: Pass a request down a chain of objects until an object handles it.
- Virtual Machines: simulated processors.
- Interpreter: Execute a program written in the inter-preter’s language.
- Rule-based Interpreter: Execute a rule set using a fact base.
- Convenience Patterns: simplified coding.
- Convenience Method: Simplify method invocations by suppressing parameters whose values are the same for many calls.
- Convenience Class: Simplify method invocations by storing parameter values in the class.
- Default Class: Provide a default implementation of a class that normally must be reimplemented by the client. Subclasses override only the methods for which the defaults are inappropriate.
- Null object: Eliminate frequent tests for null references by replacing null references with a reference to the null object.
- Compound Patterns: patterns composed from others, with the original patterns visible.
- Model-View-Controller: Provide multiple, dynamic views on shared data and dynamically change responses to user input.
- Bureaucracy: Organize objects in a hierarchical structure such that it maintains its inner consistency by itself.
- Active Bridge: Connect an application to event-driven resouces in a portable way.
- Concurrency: controlling parallel and concurrent execution.
- Distribution: problems germane to distributed systems.
References
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm
[3] Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995.
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995.
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343.
[6] Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.
[7] Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.
[8] Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University