Chapter 5. Software design patterns

Every year people's expectations of software get higher and every year the job of being a software engineer gets harder. The only way we can hope to keep our heads above water is to continually improve the tools of our discipline.

Software engineers are always looking for a higher-level way of working, a tower to climb to get some perspective. We go from low-level languages to high-level languages, we use object-oriented methods , and over time we learn a number of reusable idioms. And now there's a new route to higher ground: the use of software design patterns. Adding another layer to the UML dependency diagram (Figure 4.1) we now get Figure 5.1.

Figure 5.1. Levels of design

While object-oriented software engineering encourages us to think about encapsulating our data and methods into classes, software design patterns show us good ways to get our classes to collaborate with each other.

It turns out there are certain useful but non-obvious ways in which one can have classes interact with each other, and a certain limited number of these design patterns recur over and over again. The simpler kinds of patterns are simply idioms, but the more complicated ones are what we call software design patterns. In recent years , software engineers have taken to cataloging software design patterns.

Repositories of these patterns can be found online and in textbooks such as Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995). The pattern names used in the Design Patterns book include Abstract Factory, Builder, Singleton, Adapter, Bridge, Composite, Decorator, Fa §ade, Flyweight, Proxy, Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, and Visitor.

A software design pattern is usually described in terms of being a solution to a certain type of problem in a particular context. In this chapter's brief overviews, seven patterns are documented by describing the kind of problem the pattern is useful for, and giving a brief summary of the solution presented by the pattern followed by a mention of how the pattern is used in the Pop Framework.