Patterns
We can sum up the conclusions from these two examples by saying that – for those developers with experience of control system design, or the use of LED displays – the tasks are straightforward: however, for those without such experience, even the small- est of decisions can have unexpected repercussions. Unfortunately, the standard design notations that have been developed do not provide any means of substituting for the lack of experience on the part of a particular designer. The consequence is not difficult to predict, and is summarized succinctly in this quotation from an experienced devel- oper of embedded applications: ‘It’s ludicrous the way we software people reinvent the wheel with every project’ (Ganssle, 1992).
To address these problems use of ‘objects’, ‘agents’ or any new form of software building block or design notation will not greatly help. Instead, what is needed is a means of what we might call ‘recycling design experience’: specifically, we would like to find a way of incorporating techniques for reusing successful design solutions into the design process.
Recently, many developers have found that software patterns offer a way of achiev- ing this. Current work on software patterns has been inspired by the work of Christopher Alexander and his colleagues (for example Alexander et al., 1977; Alexander, 1979). Alexander is an architect who first described what he called ‘a pat- tern language’ relating various architectural problems (in buildings) to good design solutions. He defines patterns as ‘a three-part rule, which expresses a relation between a certain context, a problem, and a solution’ (Alexander, 1979, p.247).
For example, consider Alexander’s WINDOW PLACE pattern, summarized briefly in Figure 2.8. This takes the form of a recognizable problem, linked to a corresponding solution. More specifically, like all good patterns, WINDOW PLACE does the following:
● It describes, clearly and concisely, a successful solution to a significant and well- defined problem.
● It describes the circumstances in which it is appropriate to apply this solution.
● It provides a rationale for this solution.
● It describes the consequences of applying the solution.
● It gives the solution a name.
This basic concept of descriptive problem–solution mappings was adopted by Ward Cunningham and Kent Beck who used some of Alexander’s techniques as the basis for a small ‘pattern language’ intended to provide guidance to novice Smalltalk program- mers (Cunningham and Beck, 1987). This work was subsequently built upon by Erich Gamma and colleagues who, in 1995, published an influential book on general- purpose object-oriented software patterns (Gamma et al., 1995).
For example, consider the OBSER VER pattern (Gamma et al., 1995), illustrated in Figure 2.9. This describes how to link the components in a multi-component applica- tion, so that when the state of one part of the system is altered, all other related parts are notified and, if necessary, updated. This pattern successfully solves the problem, while leaving the various system components loosely coupled, so that they may be more easily altered or reused in subsequent projects.
As described by Gamma et al., a subject may have any number of observers, all of which are noti- fied when the state of the subject changes: in response, observers will (usually) synchronize their state with the subject’s state, illustrated schematically as:
One of the situations is which OBSER VER may be applied is when a change to one component requires changing others, and you do not know how many other components need to be altered.
One important consequence of using this pattern is that the various communicating components are loosely coupled together: this means, for example, that new components can be added, or existing components can be removed, with little impact on the rest of the program.