8.2 Design Patterns

Definition and Structure of a Design Pattern

A reusable design must include more information than just the design diagrams. For example,the problem that the design is meant to address must be defined. This information is important because it allows potential reusers, faced with a particular problems, to indentify available designs that are candidates of reuse. Another kind of infomraiton that is needed ina reusable design is the trade-offs imlied by the design. Typically designers must achieve a balance between such competing goals as efficiency, flexibility, fault tolerance, and simplicity (among others). A single problem may give rise to several useful designs, each design offering a different balance among the design factors.

A design pattern is a proposed format for presenting a reusable design. The structure of a design pattern is defined the book "Design Patterns" by Gamma, Helm, Johnson and Vlissides (page 360) as:

A design pattern systematically names, motivates, and explains a general design that addresses a recurring desing problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.

The content of a design pattern is the following twelve elements:

name

each pattern has a unique, short descriptive name. The collecton of pattern names creates a specialized vocabularly that designers can use to describe and discuss design ideas.

intent

The intent is asuccint (1-3 sentances) description of the problem addressed by the desing pattern. The intent is useful in browsing design patterns and it aids in recalling the prupose of a pattern when the name alonw is not a sufficient reminder.

motivation

The motivation explains a typical, specific problem that is representative of the broad class of problems that the pattern deals with. It should be clear from the motivation that the problem is widespread and nontrivial. The motivation usually includes class diagrams and/or object diagrams along with a textual description.

applicability

This element is a list of conditions that must be satisfied in order for the pattern to be useable. The conditions express goals that the designer is trying to achieve (e.g., the ability for "clients to be able to ignore the difference between compositions of objects and individual objects"), complicating aspects of the problem (e.g., "An application uses a large number of objects."), and constraints (e.g., "Storage costs are igh because of the sheer quantity of objects.").

structure

A description of the patternusing class diagrams and object diagrams is given here. The class names and object names are generalizations of those that appear in the specific example given in the motivation. For example, the Builder pattern motivation uses an example that has a base class named TextConverter with derived classes ASCIIConverter, TeXConverter, and TextWidgetConverter. The class diagrams in the structure section names the base class Builder and has a single representative derived class named ConcreteBuilder.

participants

Each class in the structure section is briefly described. The description is a list of each class's responsibilities and purpose in the design.

collaborations

The important relationships and interactions among the participants is described. Object interaction diagrams may be used to show a complex interaction sequence.

consequences

This section explains both the positive and negative implications of using the design pattern. Positive implications might be increased flexibility, lower memory usage, easier extensibility, support for particular functionality, or simplified usage. Negative implications might be inefficient behavior in particular cases, complex class structure for certain problems, loss of guarantees of system behavior, overly general design with attendant loss of performance or storage costs. It is important that authors of desing patterns present, and readers of design patterns understand, both the positive and negative consequences. All designs achieve a compromise among many competing forces and no desisgn can avoid have some negative consequences.

implementation

A representative implementation is shown for the classes given in the structure section. Because the structure section is generalized, so also is the implementation provided in this section. This section is meant as a high-level guide on how to represent the pattern in a given programming language.

sample code

The essential code for a typical problem (often the one presented in the motivation) is given. This code illustrates in detail hw the pattern would be applied to the particular problem.

known uses

This is a list of systems, libraries, tools, or frameworks which have dealt with the design problem addressed by this design pattern. The example systems may have used a variation of the desing pattern as a solution.

related patterns

Other design patterns that are thought to be useful in combination with this pattern are listed. This list provides additional guidance to designers by offering pointers to other patterns that are potentially useful.

An Example of a Design Pattern

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and composites of objects uniformly.

The applicability section defines two conditions: (1) part-whole hierarchies are being represented, and (2) uniformity of treatment for parts and a whole is sought. The conditions mirror the basic ideas presented in the statement of the pattern's intent. The structure section contains the following generalized class diagram:

In the generalized class diagram, the specific kinds of "parts" are represented by a single class "Leaf" while the class named "Composite" represents a "whole". The abstract base class, "Component", defines an interface that must be implemented by Leaf classes and the Composite class. The abstract base class reflects the uniform treatment of Leaf and Composite objects. Note also that the generic "Operation" method is an abstraction of some application-specific operation.

The participants section lists the responsibilities of each of the four classes that appear in the structure (Component, Leaf, Composite, Client). For example, the responsibilities of the Composite class are: to define the behvior of "a composition of ojbects, to store the composed (sub)objects, and to implement the operations defined in the abstract base class."

The collaborations section defines how the Composite pattern's participants work together to meet their individual responsibilities and achieve the effect intended for the pattern. For example, in the Composite pattern, the client interacts with the (Leaf or Composite) objects only through the abstract interface defined in the Component class. This collaboration captures a key feature of the pattern: the clinet is able to manipulate Components without regard for whether they are Leaf class objects or Composite class objects.

Two of the consequences of using the Composite pattern are:

• it makes it easy to add new kinds of basic components (i.e., Leaf classes); they are simply added as another class derived from Component.
  
• it can make the desing overly general in those cases where only certain combinations of objects have semantic meaning (for example, a document may be viewed as a Composite of paragraphs, tables, sections, etc.. However, a correct document must have exactly one title and a table may not have sections within it. It is difficult to enforce these kinds of restrictions with the Composite pattern as the pattern places no limitations on the way in which a Composite can be formed.
  

The implementation section presents issues relevant to the detailed coding of the classes in the pattern. For example, the trade-off between safety and transparency is considered in this section of the Composite pattern. This trade-off involves where to place the methods for manipulating the children of a Composite. If these methods are placed only in the Composite class it is safer (because attempt to apply them to Leaf components is detected as a compile-time error) but it is less transparent (because Leaf and Composite objects cannot be treated as uniformly as might be desired). Placing the methods in the Component base class yields the opposite trade-off. A compromise strategy introduces a methode Composite* Get Composite() in the Component base class. This method is defined in the Leaf derived class to return a null pointer and defined in the Composite derived class to return its this pointer. This strategy minimizes the loss of transparency (all base class methods apply equally to both Leaf and Composite objects) while retaining a large measure of safety (leaving to the Client the responsibility to differentiation between objects of the two derived classes).

The sample code section gives C++ code for an example of a part-whole problem. This, most detailed, level of presentation helps to give a concrete representation of the pattern that can be compiled and used for experimentation.

The known uses section lists three application domans (user interface toolkits, a compiler, and financial portfolios) where the pattern has been observed.

Finally, four related patterns are noted, including the Iterator pattern that can be used to traverse composite structures.

Summary

the ultimate value of design patterns will only be realized by an organized, extensive collection of patterns that encompasses both generic design problems as well as probmes that are specific to particular applications domains. One might imagine a collection of patterns for real-time systems, distributed/concurrent/parallel applications, and other important application areas. The collection of patterns in the Design Patterns book is an important beginning.