Design Patterns

Rarely is a significant problem solved by a single class, or a small set of classes. Rather, modern software is a complex interconnected network of objects.

As more OO systems are developed, we have noticed that over and over similar architectures arise. This is not surprising... software solves problems in established domains, and it is reasonable for two different systems that are operating to solve the same problem might have similar internal structure (assuming both are "good" designs).

Researchers have started collecting these abstract, common architectural chunks and are calling them design patterns. A design pattern is a collection of objects (classes) that have the functionality and internconnectivity specific to solving a general problem.

The classes in a design pattern work together to produce the solution.

A pattern serves as a guide for creating a "good" design for a new system.



Varieties of Classes



Application Frameworks

Let's draw a distinction between patterns and frameworks. A framework is a set of specific classes that cooperate closely with each other, making a reusable design for solving a general category of problems. A framework is usually discussed as being implemented for a specific platform. MVC as implemented in Smalltalk is a framework. Xtk is a framework; CORBA is a framework; Java Beans is a framework.

A developer customizes a framework to a particular application by subclassing and composing instances of framework classes.

A pattern is more abstract, taking on different specific forms for different platforms. Two different frameworks might both be based on one design pattern.

A pattern is therefore less specalized; a framework is specific to a particular application domain.

Frameworks can be embodied in code, they are concrete. Only examples, instances of a pattern can be embodied in code.

Frameworks are bigger than patterns. They are composed (ideally) from a collection of instances of patterns.

A framework is executable software; a design pattern is captured experience (knowledge?) about software.



Design Patterns

Here are various definitions of patterns: A good pattern meets these criteria:

Inheritance vs. Delegation

Many of the patterns that are popular and useful help you decide when to use inheritance vs. when to use delegation. notes

Intermediary patterns

This general pattern performs a standing in place of service. The pattern consists of a client object, which is interacting with another object, the intermediary. The intermediary is apparently providing some service to the client, but in reality the intermediary is simply acting as an interface to one or more other objects that are servers.

There are several named flavors of pattern intermediary. All share the characteristic that the intermediate is rather lightweight, not doing much complicated computation or data generation. It mainly exists to gather commands and farm them out appropriately to servers that can handle them.



Traversal patterns

When data values are organized into composite structures you often need to traverse the data structure processes each value is some way. Uses of these patterns vary in the processing task for each node, the form of data in the nodes, the regularity of the data structure, etc.



Combining patterns: Model-View-Controller

Often called a paradigm, MVC is a specific arrangement of three varieties of classes for presenting a user interface. Before MVC, user interfaces were built so that the three functions in MVC were mingled and indistinguishable as components of the solution. MVC defines them as recognizable objects, each with well-defined tasks.

Model is a data manager class. It implements the application class, the basic functionality of the system. It might be something like a simulation, a database, an editor, etc.

View is an observer class. It presents some representation of the data in the model.

Controller is a data sink class. It defines the way the user interface reacts to user input.

One nice aspect of the separation in MVC is that different views can be imposed on one model. That way, different users with different needs can have specialized presentations without disturbing the implementation of the model itself.

Similarly, different controllers (with ot without multiple views) can be applied to a model. In this way, users in a multi-user system can specify varying levels of local vs. remote processing. For example, in a editor, a user might specify through the controller that information is not transmitted to the model except on ; alternately, each character typed might be transmitted to the model; perhaps information is sent paragraph-by-paragraph... etc.

Some users might prefer pop-up menus for input, others might like command keys, others text-line input. Different controllers can accomodate this heterogenity without changing the underlying application (model) or the presentation (view).



summary



References

  1. WUSTL Pages on Design Patterns

  2. "Design Patterns: Elements of Reusable OO Software", Gamma, Helm, Johnson, and Vlissides (Addison-Wesley, 1995).

  3. "An Introduction to Object-Oriented Programming," T. Budd (Addison-Wesley, 1997).