A Formal Definition of Pattern
Components
Recall from Components.htm that a system is a network of components:
Recall that a simple software component is implemented by a collaboration:
Inside the shipping collaboration we might find that a shipper keeps the method of shipping in a separate ShippingMethod object. When asked to ship a purchase to a customer, the shipper delegates to the shipping method object to decide if the purchase should be shipped by land, sea, or air:
Inside the billing collaboration we might find that the
Billing component delegates to a tax calculator to decide how much sales tax to
add to the invoice. This object determines if
Parameterized Collaborations
Sometimes radically different components can be implemented by collaborations that are only superficially different. In other words, the structure and behavior of the collaboration is the same, but the names of the participants, perhaps the names of the attributes and methods are different.
For example, we might notice that both of the collaborations above are instances of the same collaboration template:
Just as we think of a generic class in Java as a class parameterized by types:
List<String> a; List<Integer> b; List<List<Char>> c;
We can think of Context, Strategy, and ConcreteStrategy as type parameters in the above strategy template. The official UML icon is:
This icon is cumbersome and useless. By using labeled dependency arrows we can show the binding of parameters to arguments.
Here it is for the Shipper example:
Here it is again for the Billing example:
Specifying Behavior
A class diagram specifies the structure of a collaboration. We can use a sequence diagram to describe the component's behavior. For example, here's the behavior of the strategy collaboration:
Design Patterns
A design pattern is a parameterized collaboration that solves a recurring design problem:
In this diagram we see that both Pattern3 (with parameters X, Y, and Z) and Pattern4 (with parameters A, B, and C) are solutions to the problem. The designer can choose. (Often a pattern will have stated disadvantages and advantages depending on the context.)
The diagram also shows that Pattern3 uses Pattern1 (with parameters U and W) and Pattern2 (with parameters J and K). Pattern4 also uses Pattern2. Pattern3 might be a composite pattern and Pattern1 and Pattern2 are its components. In other words, Pattern1 and Pattern2 work together so often that their combination is a pattern (Pattern3). In the case of Pattern4 it might be the case that its use in this particular situation created or failed to solve a secondary recurring design problem that had to be solved using Pattern2. We say that Pattern2 refines Pattern4.
Our strategy collaboration above is actually the Strategy design pattern.
Pattern Catalogs
A pattern catalog is a collection of design patterns. Each pattern in the catalog might be described using some elaboration of the Problem-Solution format:
Pattern: Strategy
Problem: The algorithm a provider
object uses to implement a particular operation may need to be changed by its
client at runtime.
Solution: Place the algorithm in a
separate strategy object. Implement the operation in the provider object so
that it delegates to the algorithm in the strategy object. By introducing a
strategy interface that all strategy objects must implement, strategies objects
become dynamically interchangable in the provider object.
Structure: Class diagram goes
here
Behavior:
Sequence diagram goes here
A pattern catalog entry might also include:
Other Names: ...
Advantages: ...
Disadvantages:
Known uses: ...
Variations: ...
Sample implementation: ...
Pattern Categories
A pattern catalog might also categorize patterns in some useful way so that they are easier to locate. Here are some examples of pattern categories:
Architectural Patterns
Structural Patterns
Behavioral Patterns
Creational Patterns