design patterns

Design patterns are an attempt to abstract and general-ize what is learned in solving one problem so that it can be applied to future similar problems. The idea was first applied to architecture by Christopher Alexander in his book A Pattern Language. Alexander described a pattern as a description of situations in which a particular problem occurs, with a solution that takes into account the factors that are “invariant” (not changed by context). Guidance for applying the solution is also provided.

For example, a bus stop, a waiting room, and a line at a theme park are all places where people wait. A “place to wait” pattern would specify the problem to be solved (how to make waiting as pleasant as possible) and suggest solu-tions. Patterns can have different levels of abstraction or scales on which they apply (for example, an intimate the-ater and a stadium are both places of entertainment, but one is much larger than the other).

Patterns in turn are linked into a network called a pat-tern language. Thus when working with one pattern, the designer is guided to consider related patterns. For exam-ple, a pattern for a room might relate to patterns for seating or grouping the occupants.

Patterns in Software

The concept of patterns and pattern languages carries over well into software design. As with architectural patterns, a software pattern describes a problem and solution, along with relevant structures (see class and object-oriented programming). Note that patterns are not executable code; they are at a higher level (one might say abstract enough to be generalizable, specific enough to be applicable).

Software patterns can specify how objects are created and ways in which they function and interface with other objects. Patterns are generally documented using a common format; one example is provided in the book Design Pat-terns. This scheme has the following sections:

•  name and classification

•  intent or purpose

•  alternative names

•  problem—the kind of problem the pattern addresses, and conditions under which it can be used

•  applicability—typical situations of use

•  structure description—such as class or interaction diagrams

•  participants—classes and objects involved in the pat-tern and the role each plays

•  collaboration—how the objects interact with one another

•  consequences—the expected results of using the pat-tern, and possible side effects or shortcomings

•  implementation—explains a way to implement the pattern to solve the problem

•  sample code—usually in a commonly used program-ming language

•  known uses—actual working applications of the pattern

•  related patterns—other patterns that are similar or related, with a description of how they differ

An example given in Design Patterns is the “publish-subscribe” pattern. This pattern describes how a number of objects (observers) can be dependent on a “subject.” All observers are “subscribed” to the subject, so they are noti-fied whenever any data in the subject changes. This pattern could be used, for example, to set up a system where differ-ent reports, spreadsheets, etc., need to be updated whenever notified by a controlling object that has received new data.

Some critics consider the use of patterns to be too abstract and inefficient. Since a pattern has to be re-imple-mented for each use, it has been argued that well-docu-mented, reusable classes or objects would be more useful.

Proponents, however, argue that “design reuse” is more powerful than mere “object reuse.” A pattern provides a whole “language” for talking about a problem and its proven solutions, and can help both the original designer and oth-ers understand and extend the design.