Design Patterns Notes

Posted by admin on July 15, 2009 under Software Architect | Be the First to Comment

Overview of Design Patterns

The concept of patterns was first introduced by Christopher Alexander in his work The Timeless Way of Building (1977). His patterns were originally aimed to capture knowledge and experience for designing and constructing buildings. Alexander noticed that all good architecture designs share a set of successful solutions. He called these principles patterns and catalogued a set of patterns in a patterns language.

Alexander (1977) described patterns as descriptions of recurring problems in the environment and a core solution that can be reused to solve each problem. He further explained that, “Each pattern is a three-part rule, which express a relation between a certain context, a problem and a solution.” (Alexander, 1977).

It turned out that the same situation applies to software too: good software tends to share a set of good principles, for example, good software tends to have highly cohesive and loosely coupled architecture. These principles may be captured in software patterns too. While Alexander’s patterns concern with only architecture design, software patterns may be further classified into analysis patterns, design patterns, architectural patterns, accountability patterns and idioms (Hohmann, 1998). These patterns capture recurring solutions concerning different areas, i.e. architecture, analysis, design etc. Idioms are patterns concerning a particular programming language, while accountability patterns are for managing organisational structures.

Design patterns capture the static and dynamic structures of solutions that occur repeatedly when producing applications in a particular context (Coplien and Schmidt, 1995). “A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies participating classes and their instances, their roles and collaborations, and the distribution of responsibilities.” (Gamma et al., 1994). In another words, design patterns not only capture well-tested solution to a set of recurring problem, they also capture the knowledge and wisdom behind the use of the solution in a particular context.

Design Patterns – Related Works

After the publication of Design Patterns (Gamma et al., 1994), software patterns became very popular among the object-oriented community. Other software engineers had started adopting patterns for different usage.

Cunningham and Beck (1987) developed design patterns specifically for Smalltalk program design. Coplien (1992) works on C++ idioms, which are patterns related to C++. Fowler (1996) discusses analysis patterns while Coplien (1997) addresses organisation patterns. Hillside Group (1998) also set-up a web site dedicated to patterns.

Documenting Design Patterns

In The Timeless Ways of Building (Alexander, 1979), Alexander identified three essential elements that should exist within any pattern, they are:

1. a rule to identify the relationship between the pattern and its context;
2. a system of forces which arises within the context;
3. a solution or configuration which resolve the forces within the context.

In the software engineering community, a different format that had been used to describe patterns, depending on the author of different “patterns handbook”. Appleton (1997) had highlighted the following elements.

• Name – a unique and meaningful name to identify the pattern. The pattern name should form a vocabulary for communication among software engineers; it should also reflect the structure or knowledge that the pattern describes. Patterns writers should be aware of other aliases commonly used in the industry and document them too.
• Problem – statement to describe the intention of the pattern, such as its aims, objectives and motivation.
• Context – a description of the environment in which the pattern is applicable; this may be viewed as the preconditions for applying the solution.
• Forces – the notion of force generalises the kind of criteria that software engineers use to justify designs and implementations (Lea, 1997). This component contains a description of the forces within the context and how they affect each others. Evaluating the effect of these forces, software engineers would consider various trade-offs for applying the solution.
• Solutions – patterns describe solutions as a collection of static and dynamic rules that should be applied for solving the problem while maintaining a balance among all forces. The pattern should describe not only the static structure but also the dynamic behaviour of the solution. It is possible that variants of the solution exist, which should be described in the pattern too.
• Examples – examples of how to apply the pattern would help pattern users understand the pattern’s use and applicability better, this is especially important to new pattern users.
• Resulting Context – Applying solutions onto an existing context would transform the system into a resulting context; pattern users should understand the consequences of applying the solution, as well as other problems or patterns that might arise in the new context. In another word, this component captures the post- conditions and side effects (Appleton, 1997) of the pattern.
• Rationale – since patterns exist together with a set of forces within a particular context, there must be a rationale to justify the use of the proposed solution as well as the way the solution resolves these forces. This component tells why a solution works, why it is “good” and how it works.
• Related Patterns – this element identifies any dynamic or static relationship with other related patterns. These relationships may exist because of similar initial or resulting context, sequence of applicability, similar forces, or dependence among the patterns.
• Known Uses – The Rule of Three (Hohmann, 1998) says that unless the solution described in the pattern has been used in at least three systems, it is rarely considered a pattern. Since patterns are “proven solutions to solve recurring problems”, it is very important to document known uses to prove that the solution proposed is indeed proven; on the other hand, such documentation would serve as examples too.

One quality that Hohmann (1998) suggested is the balance of information and being brief – from one to four pages in length.

Software Design Pattern – Promises and Pitfalls

The use of design patterns has the potential to deliver some significant benefits to the development environment. Design patterns are a form of high level reuse, mainly the reuse of design. By reusing proven designs, designers need not solve every problem from first principles. They need not design all solutions from scratch; thus, it is possible to reduce time required for design. Reusing proven designs also helps to maintain characteristics of good design too.

The use of patterns (not only design patterns) also provides the development community a common vocabulary. Since knowledge and experience are organised around large conceptual structures such as algorithms (Gamma et al, 1994), communication about such subjects are often difficult without a higher level of abstraction. By giving each piece of knowledge (pattern) a name (pattern name), communications about software systems designs becomes less complex because designers can refer to those designs without having to talk about the detail. The documentation standard for patterns, such as those used by Gamma et al(1994) helps to capture knowledge in a way that makes it easier to understand, because of their formal approach. This benefit further allows passing of knowledge to be more effective because learning and understanding of the knowledge is easier.

One of the major threats to successful usage of patterns is that like almost all hot topics, it is over hyped. Designers should not treat design patterns as “must have” and use patterns regardless of applicability. This leads to the misuse of patterns in situations where designers do not know when to use or not to use patterns.

An organisation needs to have an organisational-wide design pattern program in order to enjoy the full potential of patterns. If one of the benefits of using patterns is to provide a common vocabulary for communication among designers, then all designers should be well verse with the vocabulary. In order to fulfil this benefit, all developers have to be familiar with the same collection of patterns to a certain degree. This leads to another concern: there is not yet a methodological support for organisational-wide use of patterns. Issues like documentation, training, and assessment for the development team has to be dealt with.

The methodological support is imperative in a multi-designer environment, where a uniform level of knowledge is preferred. Imagine if an organisation has fifty developers but only eight of them know patterns. The method describes processes and methods required to achieving such environment. However there is not yet a methodological support for using patterns which also deals with patterns mining, documenting and the use of patterns. Successful organisational-wide patterns program such as those in AG Communication Systems (Goldfedder and Rising, 1996, Rising, 1996) are mainly due to very well planned approaches.

Recent rush to patterns causes increasing effort to patterns mining. One possible consequence will be the increasing number of patterns discovered. The problem that designers will face is getting familiar with design patterns and choosing which one to use. One solution is to select and use only a few common design patterns and learn more slowly over time.

Designers have to keep in mind that patterns are not design strategies. The aim of design patterns is to solve a design problem concerning a particular context. For example, “Reduce coupling among classes” (which is a design strategy) is not a design pattern.

One most important thing that all pattern users should be aware of – patterns are not the long-sought-after silver bullet. While patterns are good ways of experience reuse, they are still too high-level to support direct code reuse, a good pattern may still rendered useless when implemented wrongly. In addition, the issue of choosing the right pattern depends on the judgement of designers.

-- By HooYinn FONG