it is the rule for making the thing, but it is also,
in many respects, the thing itself.
— Jim Coplien
Christopher Alexander originally described patterns and pattern languages as a mean to improve twentieth century architectural design methods and practices. Patterns have since been shown to be applicable in many other areas as well, perhaps most notably within the field of computer science and especially manifested as software design patterns related to OO development. This chapter presents the ideas set forth by Alexander and the connection to software design patterns. We describe the core pattern concepts, such as pattern languages, entries, qualities, forces, descriptions, and formats, which must all be understood in order to understand what a pattern represents, and hence to perform a meaningful evaluation. We explain how the general pattern concepts relate to software patterns and in particular to OO and the "Gang of Four" design patterns. We also present the "Gang of Four" pattern system containing the twenty—three "Gang of Four" design patterns, and explain how the patterns are classified and related. Throughout this chapter, we try to make the theory concrete by supplying several practical examples, and we present our views on many of the discussed topics. This will help understand the practical application of the "Gang of Four" patterns in the evaluation.
3.1. Christopher Alexander
Software design patterns are based on the ideas set forth by Christopher Alexander, a licensed contractor and an architect, who introduced and explained patterns and pattern languages in [Alexander77; Alexander79]. These texts were preceded and followed by a rather large number of others on closely related topics. We only give a short (and far from complete) introduction to Alexander's numerous writings, primarily based on [Appleton97; Appleton00; Lea93] unless specifically noted otherwise.
According to Lea, Alexander postulates that there is something fundamentally wrong with twentieth century architectural design methods and practices; a certain Quality Without A Name (QWAN) is missing from constructed environments. QWAN cannot be summarised briefly and no single term exist to convey or capture its meaning, but Alexander explains QWAN using partial synonyms closely related to the human impact on the design process like freedom, life, wholeness, and harmony [Lea93]. Consequently, constructions do not satisfy the real demands of users and society, because the generated environment does not have a coherent form, thereby failing the basic requirement that design and engineering improve the human condition. His ultimate goal is to build viable living structures for the people who live and work there. To remedy these shortcomings, Alexander suggests letting the inhabitants of the towns and buildings themselves take part in the design and practices using easily understandable patterns and pattern languages. This will ensure that far more inhabitable constructions will be made - structurally and spiritually - that will have that certain nameless quality we should strive for, thus reaching a coherent form. Alexander's patterns are design patterns concerning architecture.
Alexander never gives a formal definition of a pattern or a pattern language [Lea93], but offers the following explanation [Alexander79, p.247]:
 | As an element in the real world, each pattern is a relationship between a certain context, a certain system of forces, which occurs repeatedly in that context, and a certain spatial configuration, which allows these forces to resolve themselves. As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant. |
The notion of a pattern is thus two—fold. Firstly, a pattern is an abstraction of practical experience and basic knowledge; it is not invented as such, but discovered (or mined), and Alexander even states that some patterns are universally known [Alexander79; Lea93]. The idea is to identify the conflicting forces within a given context, and then find a solution that brings them into harmony. A pattern not only identifies a solution, it also explains why the solution is needed [Appleton00]. Applying a pattern is the process that generates such a solution, but variant solutions may be generated. Alexander therefore emphasises letting the inhabitants (e.g. endusers) take part in the design and stresses that human interaction is an absolute necessity in applying patterns. In Alexander's domain of designing and constructing buildings and towns ("neighbourhoods" or "urban planning"), a context could be an entire town or just a house. Conflicting forces could be the known problems related to building, say, a house. This implies that patterns may be applicable at different levels in the design and therefore have different granularity, ordered in a hierarchical structure.
Secondly, the solution must be recorded, or described, so it can be reused in similar contexts. Alexander suggests a format to describe patterns in a literary non—mathematical form having the elements Name, Example, Context, Problem, and Solution [Lea93]. However, not everything that can be described using a pattern format can be considered a pattern. A pattern (entry) must ideally have a set of properties to ensure its quality, namely Abstraction, Composibility, Encapsulation, Equilibrium, Generativity, and Openness [Appleton00]. The pattern must also describe the forces that it balances. If well written, each description describes a whole that is greater than the sum of its parts [Lea93]. The presence of these properties combined with all the required pattern elements is what makes pattern entries more than just principles, heuristics, rules, or algorithms [Coplien, i.8-9; Lea93]. On the other hand, a pattern description will often contain the former, i.e. heuristics, etc., and use them as part of the pattern [Appleton00]. However, pattern descriptions leave room for interpretation. As Alexander desires living and constantly evolving architectures, patterns may be applied differently in equivalent contexts to reflect subtle changes. In [Alexander77], he writes:
| Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. |
The idea of using "descriptive manuals" of "Best Practices" as aids to solve a given problem is nothing new and cannot be attributed to Alexander, but Alexander views patterns as "a timeless way of building" (see [Alexander79]) rather than merely offering factual descriptions on how to solve various design problems. In Danish, there is even a specific word to describe "Best Practices" within various engineering areas, ståbi, meaning (an) assist, aid, or (a) stand by in form of some sort of manual describing optimal solutions to various technical problems5.
A pattern description can be an entry in a pattern language. As such, entries are considered elements of a language. It is therefore essential their representation is easily understandable and recognisable so the described pattern can be applied in other applicable contexts. A pattern language is comprised of a fixed number of such pattern entries, each describing a well—proven solution to a reoccurring problem within a specific context inside a larger domain. Furthermore, a pattern language should describe its context in full, but different languages can use the same (sub—) set of patterns, combined and collaborating in different ways and perhaps in some order, depending on the context. Combined, the patterns can solve a more fundamental problem that is not explicitly addressed by any individual pattern [Appleton00; Lea93]. A pattern language describing the entire domain is said to be complete. Mathematically, to our knowledge, no pattern language has ever been proven complete, which would also seem contradictory to the idea of patterns being discovered since based on practical experience.
Alexander constructs a pattern language containing 253 pattern entries of varying granularity, from regional patterns down to patterns pertaining to some small part of a house6. Alexander claims the entries form a complete architectural pattern language for his domain [Alexander77; Lea93]. From Alexander's language, smaller languages can be constructed using several of the contained patterns to describe sub—contexts. For instance, to construct a pattern language to describe a given house, some of these patterns must be used, for example patterns describing light, transitions, colours, surfaces, etc., while these and others would be required to describe an entire region. The end—user, i.e. the inhabitant, help decide which patterns to include in the language to construct the house [Lea93]. However, during several experiments using his pattern language, Alexander and others realised that it did not really work as well as intended in practice; the pattern language alone did not succeed in constructing coherent form because of too many unknowns, for example the order in which to apply the patterns. Alexander therefore introduced morphogenetic sequences, or just sequences (see [Alexander05b]). A morphogenetic sequence is a pattern language that adheres to a certain order of unfolding, i.e. the order in which patterns are applied one after another. A sequence causes a repeatable coherent order to unfold, which also contains the patterns and therefore is well behaved as an environment [Alexander05b]. Alexander's, as of yet, final modification to pattern languages is generative codes [Alexander05a]. Generative codes are also morphogenetic sequences, but include all information needed for practical implementation, especially concerning human interaction, as well as practical, legal, and procedural details. Alexander states that without the use of generative codes, the practical work cannot be done successfully.
3.2. Software Patterns
While Alexander describes patterns to supply solutions to problems related to his domain of designing and constructing buildings and towns, patterns and pattern languages can be, and have been, applied elsewhere, especially within the field of Computer Science.
Around 1987, Beck and Cunningham were among the first to apply the Alexander's ideas to computer science. They constructed a pattern language containing five pattern entries describing how to design simple Graphical User Interfaces (GUIs) in Smalltalk, targeted at novice Smalltalk programmers [Beck87]. The patterns were not only related to design, but also to Human Computer Interaction (HCI) in the sense that they focused on the usability of the resulting design. The patterns had varying granularity and were hierarchical related, yielding an order of application.
In 1991, Jim Coplien published a book containing a large collection of C++ idioms [Coplien91]. The book does not explicitly use the term pattern, but it was published years before the patterns became popular within computer science. However, the idiom classification of design patterns from the taxonomy listed in table 2.3 seems quite influenced by his work. In the early nineties, various people now considered pattern notables began collecting and discussing software patterns, but software patterns first became truly popular after the "Design Patterns" book by Gamma et al. was released in 1995. The four authors became known as the "Gang of Four", and the patterns presented in the book as the "Gang of Four" design patterns. The "Design Patterns" book not only describe twenty—three software design patterns describing communicating objects customised to solve a general design problem in a particular context [Gamma95, p.3], but also discuss the overall OO concepts and themes the patterns express (as explained in section 2.1.1 and 2.1.2). The "Gang of Four" patterns have long since become famous and used extensively within the OO community. Many other books on patterns have since been published, far too many to give a meaningful and comprehensive list, and there are conferences dedicated to patterns held regularly, such as the Pattern Languages of Programs (PLoP) conferences. The "POSA" books by Buschmann et al. [Buschmann96; Schmidt00] are also widely used; Buschmann et al. formulated the design pattern categories commonly used to this day, i.e. the architectural patterns, design patterns, and idioms categories from table 2.3. Besides books and conferences, online pattern repositories such as [PPR] and [Hillside] also provide much information regarding software patterns.
It is important to state that software patterns are not restricted to software design patterns, but it is hard to estimate how influential Alexander's work has been on different kinds of patterns and individual collections, whether intentionally or not. For example, many of Coplien's C++ idioms are not really patterns, while Beck and Cunningham directly references Alexander and claims that their five patterns form a complete pattern language [Beck87]. Though not to the same extent as Beck and Cunningham, Gamma et al. clearly state that they build on the work by Alexander [Gamma95, p.2-4], and Buschmann et al. relate their work to Alexander as well [Buschmann96, p.360,414; Schmidt00, p.505-526]. But one thing is saying so, another thing is doing so. Alexander's work related to software (design) patterns is debated heartily within the community, also with respects to the "Gang of Four" patterns (see for example [PPR]). On the other hand, pattern related concepts originating in computer science have also emerged, such as The Rule of Three and Proto Patterns as explained in section 3.8.3. Furthermore, as discussed in section 3.6, efforts are also being made to formalise pattern descriptions and include patterns as language features or implement them as reusable components in accordance with the principles in OO. This approach to design patterns deviates from the original concept defined by Alexander in the sense that the human factor is less important in applying the patterns, but is much more tangible and structured.
More recently, different kinds of software patterns have emerged outside the scope of "mere" OO design, such as Analysis, HCI, Organisational, or Process Patterns, used to describe other or more specialised aspects of software engineering [Appleton]. Analysis patterns as described by Fowler are still closely related to design [Fowler97], and are therefore included in our pattern taxonomy, while HCI patterns seem quite well suited to expand on Alexander's ideas in different ways than OO design has. This is because several verbose, but exactingly formulated, HCI methodologies already exist, based on empirically proven design guidelines, such as User—Centred Design (UCD) in which the end—user must participate wholeheartedly in the design of the solution [Borchers99]. This is reminiscent of Alexander letting the end—user participate in the design process. HCI is very much based on practical experiences, and because of characteristic similarities with patterns, HCI methodologies could be expressed using pattern descriptions, especially since the methodologies already have a written form.
Still, software design patterns related to OO are very likely the most used kind of software patterns. People within the software community neither accept the usefulness of individual patterns or collections, nor the need for such a thing as software design patterns at all. OO has always acknowledged the need for meticulous analysis (OOA) and design (OOD), but prior to design patterns, descriptions of design problems where mostly of a rather abstract nature describing from scratch how to identify the individual parts of the system, their relationships, and collaborations. In our view, a textbook example of this is the otherwise good book "Designing Object—Oriented Software" by Wirfs—Brock et al. from 1990 [WirfsBrock90]. With patterns, problems of varying granularities have already been solved and described, giving the designer a new set of "broader" tools to use in the analysis and design phase. The abstraction need no longer be just focused at the individual class and object level, but also at a higher level describing functionality, relations, and coherency traditional OO constructs cannot. The principles are thus separated from the implementation. We think this is a key reason behind the popularity of software design patterns.
3.3. Pattern Qualities
A pattern entry must ideally possess the set of properties listed in table 3.1 to ensure the quality of the pattern, namely Abstraction, Composibility, Encapsulation, Equilibrium, Generativity, and Openness [Appleton00]. Many of these properties have similar meaning to desirable constructs in OO, which could explain why software patterns first became popular within this domain. As an example, consider a class. A class is an abstraction with encapsulated responsibilities representing some equilibrium. It can be used as a component by other classes and is normally generative in its usage. It can be implemented in different languages or may even be parameterised with other types (openness) [Lea93].
Lea even writes that patterns may be viewed as extending the definitional features of classes, and that classes and patterns have two analogous aspects [Lea93]:
- The external, problem—space view: descriptions of properties, responsibilities, capabilities, and supported services as seen by the external context; and
- The internal, solution—space view: static and dynamic descriptions, constraints, and contracts among components known only with respect to a possibly incomplete external view (interface).
The need for these qualities implies that there is no guarantee that a given problem can be solved using a pattern. Not every solution can be captured in a pattern, and not everything described by a pattern entry can be considered a pattern [Hohmann98]. Accordingly, a class will only express these properties if well designed.
 |  Table 3.1 — Pattern qualities | ||
| Name | Description | Computer Science | |
| Abstraction | A pattern represents a general abstraction of knowledge and experience within a given domain [Lea93]. The use of natural language, diagrams, illustrations, etc., is required. | Objects are programmatic abstractions of functionality, real—world or otherwise. A pattern abstraction is a higher—level abstraction compared to what can be described by programming language constructs alone. The use of programming language in examples augments the pattern description, but the examples cannot stand—alone. | |
| Composibility | Patterns of different granularity are hierarchically related (in a pattern system or language), indicating a rough application order to be adhered to when the patterns are unfolded. Patterns at a given level of abstraction and granularity may lead to, or be composed with, other patterns [Alexander77; Appleton00; Lea93]. | Objects share similar traits, and can be composed to achieve complex functionality. For example, a recurring theme in [Gamma95] is to prefer delegation to inheritance, which allows for dynamic composibility. | |
| Encapsulation | A pattern must encapsulate an independent, well—defined real—world problem and solution within a given domain [Alexander77; Lea93]. | An object uses encapsulation to ensure that both data and the methods that operate on the data are correlated. Combined with information hiding, this ensures that the responsibilities of the objects are well—defined. However, an object need not represent a real—world problem. | |
| Equilibrium | Indicates a balance between forces and constraints that minimises the conflicts in solution space identified by the pattern, and may be based on invariants and/or heuristics. Equilibrium provides a rationale for each individual step in the pattern when applied [Alexander77; Appleton00; Lea93]. | The responsibilities of an object represent the trade—offs made when designing it, and the functionality implemented by the object represents the equilibrium. | |
| Generativity | When a pattern is applied, as described by its description, it provides the solution to a given context thereby generating a new resulting context, which in turn can be used to apply other patterns, and so forth, leading to the overall generation of the solution to the domain in question. More than one pattern may be applicable to a given context [Alexander77; Lea93]. | Classes can be viewed as being generative as well; they support parameterised instance construction and perhaps parameterised types (e.g. generics and templates). Objects in prototype—based languages may also support parameterised instance construction. | |
| Openness | Each pattern should be open for extension and parameterisation by other patterns, to work together to solve a larger problem. Realisation of the pattern should be possible using any number of implementations, alone or in conjunction with other patterns [Alexander77; Lea93]. Applying a pattern is the process that generates a solution, but it may generate variant solutions [Appleton00]. In theory, a pattern entry should be implemented for each usage. | Some languages contain built—in support for several patterns, and libraries are commonly used to supply well—proven pattern implementations (see section 2.6.2). Combined with parameterised types (e.g. generics or templates) even built—in classes may be considered open, for example java.util.Iterator<E> in Java. | |
If a pattern exhibits these qualities, the source code implementation is likely to reflect them as well.
|
Example 3.1 — In example 2.4, we claimed that the Abstract Factory, Factory Method, and Singleton patterns could aid in the design of the notification mechanism from example 2.1. To add value to the design the patterns must express the desired qualities. The Abstract Factory pattern is an abstraction of knowledge about creating objects without explicitly knowing their type; its description contains text, illustrations, as well as program code (Abstraction). The pattern functionality is required in many different types of flexible real—world systems, and the pattern encapsulates this task by providing a description of the problem as well as a proven solution to it (Encapsulation). The description explains the trade—offs in using it, for example that the pattern promotes consistency, but also that it can be hard to add new types of object to a given factory (Equilibrium). The Abstract Factory can defer the actual creation of new objects elsewhere, typically to Factory Method or Prototype [Gamma95, p.117] pattern implementations (Composibility and Openness); as a variant, it could also choose to implement the functionality by it self, for example using reflection in Java (Openness). Finally, Abstract Factory implementations are often suitable as candidates for the Singleton pattern (Generativity)  |
3.4. Pattern Forces
A pattern must balance opposing forces within its context to reach a balance that implicitly will be present in the pattern and in its application [Appleton00]. The described solution must bring the identified forces into harmony, or the pattern is not warranted. This implies that a pattern may represent trade—offs between various forces.
The type of forces depends entirely on the domain and context, but forces can generally be thought of as goals and constraints. In computer science, the notion of force generalises the kinds of criteria used to justify designs and implementations [Lea00, i.12]. According to Buschmann et al., the most important non—functional forces regarding OO development are Changeability, Interoperability, Efficiency, Reliability, Testability, and Reusability [Buschmann96, p.404-410], and Lea lists a set of similar forces, such as Portability, Extensibility, Fairness, Maintainability [Lea00, i.12], etc. More explicit functional forces are closely tied to the domain [Appleton00; Lea00, i.12-13]. A functional force can be visible to the users of the system by means of a particular function, or it may represent aspects of the implementation, such as the algorithm used to compute the function [Buschmann96, p.389].
Design patterns, e.g. the "Gang of Four" patterns, primarily express non—functional forces, as example 3.2 below also illustrates. As patterns are used to implement system functionality, the forces balanced in the pattern may influence the system unless fully encapsulated, intentionally or otherwise. Similar, the traits of the system will dictate the type of applicable patterns.
|
Example 3.2 — A set of non—functional forces relevant for the notification mechanism from example 2.1 could be Reusability, Changeability, and Extensibility related to the various design issues contemplated in example 2.2. If designed as an open—source library or API, Reusability becomes an important factor, as well as Changeability and Extensibility to manage or add new means of deliveries or new functionality. On the other hand, Efficiency and Fairness is not that important as long as a delivery is made eventually. As means of deliveries, we considered email and SMS deliveries in form of the EmailDelivery and SMSDelivery implementations. They are store—and—forward services, and once a message has been delivered successfully to the gateway, nothing more can be done from the application's point of view. However, other types of deliveries could require scheduling and processing guarantees, for example the order of delivery. A delivery writing to an event or audit table in a database is one example. Patterns used in the design of the notification mechanism should match these forces and preferably enforce them, for example using the Abstract Factory [Gamma95, p.87] and Factory Method [Gamma95, p.107] patterns as described in example 2.4 to ensure Changeability and Extensibility of associated Delivery and Formatter types. Functional forces will be closely related to the core functionality of the notification mechanism, which is a library for delivery of messages to subscriptions using various means of deliveries. This indicates that there will be an overlap between functional and non—functional forces in this case, e.g. Fairness and Extensibility. A more explicit functional force could be an algorithm used to correlate and concatenate related Notification objects to be delivered in a single delivery |
An example of an unresolved force relevant to the "Gang of Four" patterns is Multithreaded Safety as suggested by Lea [Lea00, i.12]. In general, concurrency is not an issue discussed much in the "Design Patterns" book [Gamma95]. This does by no means imply that the "Gang of Four" patterns are faulty, but that care must be taken when applying them in modern concurrent systems. For example, what is the result in case of concurrent modification to the underlying representation used by the Iterator pattern (robustness), or how do we ensure that only a single instance of a Singleton type is created in a concurrent environment?
3.5. Pattern Elements
Alexander's description of patterns contains certain vital elements to ensure that it conveys the relationship between the context and forces, and implicitly the qualities as well [Appleton00]. A pattern format, or just form, is a template dictating the elements and structure of pattern descriptions. To be able to reuse a pattern in a design, the pattern description must contain the decisions, alternatives, and trade—offs (forces) that led to it [Gamma95, p.6]. A well—written pattern must also express the desired qualities [Lea93], and is more than a simple recipe as Fowler explains [Fowler06]:
| Recipes tend to be more particular, usually tied to a particular programming language and platform. Even when patterns are tied to a platform, they try to describe more general concepts. |
Many different formats exist, some just slight variations of others, but no official standard is acknowledged [Lea00]. However, several de—facto standards exist. Alexander's format, Alexandrian Form, is used to describe architectural patterns and it contains the elements Name, Example, Context, Problem, and Solution [Lea93]. In computer science, the "Gang of Four" (GoF) and Canonical Forms are widely used [Lea00; Appleton], but many other exist (for a list, see [Lea00; PPR]). For instance, the "POSA" patterns are described using a variant of the Canonical Form [Buschmann96, p.20-21], while the "Gang of Four" patterns are described using the "Gang of Four" form, surprisingly enough. All forms in some way seem to present the elements required by Alexandrian Form, but not necessarily in, or as, their own sections. Some formats make these elements explicit, while others do not. For example, the form used by Fowler to describe his analysis patterns in [Fowler97; Fowler03] has just three named elements, where only the Name element corresponds to a pattern element as defined by Alexander. Hence, different pattern formats describe different elements, and elements differently, but Appleton states that the elements from the Canonical Form should be clearly recognisable upon reading a pattern description. The elements are Name, Problem, Context, Forces, Solution, Examples, Resulting Context, Rationale, Related Patterns, and Known Uses [Appleton00]. The naming of patterns is especially interesting. By giving a pattern a meaningful and concise name, designers, developers, and others share a common vocabulary (easy naming of solutions to common problems) that can be utilised in the development process, and which extends beyond other more traditional methods [Gamma95, p.6; Fowler06].
The pattern description will be affected by the domain targeted by the pattern. The "Gang of Four" design patterns operate in OO environments, and OO concepts and themes utilised by Gamma et al. will be reflected in the patterns and their application, i.e. implementation. The concepts and themes thus become important in order to understand the patterns as a whole. However, the format used to describe the patterns can also affect the pattern, because not all formats are appropriate for a given domain [Vlissides97, i.7].
3.5.1. "Gang of Four" Format
The format used by Gamma et al. in the "Design Patterns" book has since been named the "Gang of Four" format, or GoF form. The Canonical Form builds on the format, and shares many elements; it can be viewed as a generalised version of the "Gang of Four" format. The format is commonly used, and often used as a base for variant forms [Fowler06]. The format is highly structured compared to the Alexandrian form of writing, which is narrative and almost lyrical [Vlissides97, i.7]. Table 3.2 explains the general purpose of the different elements. It also relates them to the most relevant qualities from table 3.1 as we see it.
| Table 3.2 — "Gang of Four" pattern format (modified from [Gamma95, p.6-7]) | ||
| Element | Description | Qualities | |
| Name | A concise pattern name that conveys the pattern essence. | Abstraction | |
| Classification | The classification of the pattern according to the two dimensions Scope (Class and/or Object) and Purpose (Creational, Structural, or Behavioural). | Abstraction, Composibility, Generativity | |
| Intent | A short statement that answers the following questions: What does the design pattern do? What is its rationale and intent? What particular design issue or problem does it address? | Abstraction, Equilibrium | |
| Also Known As | Alternative names, if any. | Abstraction | |
| Motivation | An example that illustrates a design problem and how the class and object structures in the pattern solve the problem. | Abstraction | |
| Applicability | In which situations can the pattern be applied? What are examples of poor designs that the pattern can address? How can you recognise these situations? | Abstraction, Composibility, Generativity | |
| Structure | A graphical representation of the classes and objects in the pattern. | Abstraction, Encapsulation | |
| Participants | The classes and/or objects participating in the design pattern and their responsibilities. | Abstraction, Encapsulation | |
| Collaborations | How do the participants collaborate to carry out their responsibilities? | Abstraction, Encapsulation | |
| Consequences | How does the pattern support its objectives? What are the trade—offs and results of using the pattern? What aspect of the system structure does it let you vary independently? | Equilibrium, Openness | |
| Implementation | What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language specific issues? | Composibility, Equilibrium, Generativity, Openness | |
| Sample Code | Code fragments that illustrate how you might implement the pattern. | Generativity, Openness | |
| Known Uses | Examples from real systems. | Composibility, Generativity, Openness | |
| Related Patterns | Related patterns, if any. | Composibility, Generativity, Openness | |
The elements listed in light grey are the elements most closely related to pattern implementation, i.e. Implementation and Sample Code. As described in chapter 5, the evaluation pays special attention to these elements. The format as described in the "Design Patterns" book explicitly mentions that the Sample Code element will supply source code in C++ or Smalltalk [Gamma95, p.7], because the "Gang of Four" patterns are illustrated in these languages. Similar, the Implementation element is closely related to these languages as well, or at least the features of the languages. The use of these languages in the pattern description may influence the pattern application using other languages, e.g. Java 6, because they tie the patterns to specific languages. This is also noted by Gamma et al. [Gamma95, p.4]. As patterns are discovered in existing source code (see section 3.8.1), the Implementation and/or Sample Code elements may very well represent extracts from real systems written in the same programming language. Both the problem and solution may thus have originated in, or because of, the language in question.
3.6. Pattern Formalism
The lack of a formalised concept of a design pattern has long been a vigorously debated issue within the pattern community (see for example [Eden98, p.3; Eden02, p.380] and much of [Hillside; PPR]). It goes to the very core of understanding, or agreeing on, what software design patterns are. Formalism is closely related to tool support for pattern mining, understanding, and application. The efforts to formalise design patterns intentionally oppose Alexander's ideas of patterns languages and patterns expressing the QWAN in favour of more analytic and structural approaches [Eden98, p.3]. Practically all software design pattern formats are already much more structured compared to the Alexandrian format. Stated bluntly, Eden says most followers of Alexander's ideas treat software design patterns as sacred cows, no less, which cannot, and should not, be formalised, while followers of the efforts to bring structure, formalism, and tools to the pattern community are rational [Eden98, p.3]. In this feud, we take the middle ground. Formalism can be a valuable tool to aid the practical implementation of design patterns, i.e. componentization, tooling, and ease of understanding, while remembering that software design patterns ideally express more than program code, i.e. part of a vocabulary, highly adaptable, used for teaching and understanding of concepts, etc.
While formal specifications may clarify pattern functionality, we fail to see how it can describe the human aspect in patterns and in their application, expressed in, and as a combination of, various pattern elements. Strict formalisation of patterns will deemphasise the human aspect greatly, which goes against Alexander's original ideas. Vlissides agrees and writes [Vlissides97, i.4]:
| In short, patterns are primarily food for the brain, not fodder for a tool. There may yet be latent benefit in methodological or automated support, but I'm convinced it'll be icing on the cake, not the cake itself or even a layer thereof. |
Even more so, as described in section 3.5, different pattern formats describe different elements and elements differently. If formalism is to succeed, we believe it will be at the expense of variety of pattern formats. This could pose a problem, as a single pattern format does not fit all [Vlissides97, i.7].
Baroni et al. discuss numerous OO and pattern formalisation methods in [Baroni03], and conclude that all the reviewed mechanisms have drawbacks, and cannot capture all the concepts related to patterns [Baroni03, p.11,53]. In light of the reviews, Baroni et al. also conclude that certain pattern elements in the "Gang of Four" format are easier used in the pattern formalisation process, namely Participants, Collaborations, Structure, and in part Implementation [Baroni03, p.8,53]. As explained in table 3.2, the first three elements relate to the actual design and relationships of the classes and objects used in the pattern. Common relations like inheritance, creation, and forwarding are labelled as simple [Baroni03, p.11] and are clearly encompassed by the concepts and themes described by Gamma et al. The Implementation element primarily express programming language constructs, which are highly structured. The four elements all favour structured over unstructured information. In our view, this is a clear indication that formalisation is closer related to fundamental OO concepts as opposed to pattern concepts, such as qualities and forces that cannot easily be described. The human factor is missing. Pattern concepts are what make patterns powerful abstractions and tools, not just the OO mechanisms used to implement them. Formalism may be able to resolve some ambiguities, but literal descriptions are still warranted to describe the human aspect.
3.7. Pattern Collections
A pattern cannot describe a complete OO system by itself, but targets a specific problem within the system. Instead, patterns are often interrelated and rely on the behaviour of other patterns to achieve their own goals, especially so for patterns targeting the same domain or even context. The relations between patterns are important because applying a specific pattern may generate the need to apply other patterns; a relation can also indicate different possible solutions in form of other patterns. In the "Gang of Four" format, as described in section 3.5.1, the Related Patterns element expresses such pattern relationships. Based on how coherent a collection of patterns are, including how they individually are described, patterns can be correlated in different types of collections as explained in table 3.3 below.
| Table 3.3 — Pattern collections | |
| Name | Description | |
| Catalogue | A pattern catalogue is a collection of loosely and/or informally related patterns. The contained patterns are often divided into broad categories and are not necessarily written using uniform pattern entries or even format [Buschmann96, p.23]. | |
| System | A pattern system is a cohesive set of related patterns described in a consistent format, working together to support construction and evolution of whole architectures [Buschmann96, p.361]. | |
| Language | A pattern language can be viewed as a pattern system covering a complete domain with rules and guidelines, which explain how and when to apply its patterns to solve a problem that is larger than any individual pattern can solve [Appleton00]. | |
Pattern catalogues can evolve into pattern systems, and due to the obvious benefits of systems over catalogues, catalogues are rarely used because the knowledge they represent may be too unstructured to be truly useful in the design process. Gamma et al. identify the "Gang of Four" pattern collection as a "catalogue" [Gamma95, p.8], but according to the Buschmann et al. definition, they constitute a pattern system. This is because the "Design Patterns" book predates the "POSA" books. The "Gang of Four" design patterns all target the same domain; they are interrelated in intricate ways; many depend on other patterns to supply functionality; and they are all written using the same format.
Though pattern systems share many desirable traits with pattern languages7, they can at most be considered incomplete pattern languages [Buschmann96, p.360]. Pattern systems lack the robustness and wholeness of pattern languages. Because of narrower focus, most are described using only a sub—set of the pattern elements in the Canonical Form, but may eventually evolve into a pattern language. Pattern languages are not created all at once, but evolve from pattern systems. In practice, however, the difference can be very hard to detect [Appleton00]. Dominus, for example, states that systems and even catalogues are what many people mistake for pattern languages [Dominus02].
A pattern language can be thought of as a "super pattern" that can be applied to solve a problem in its entirety. The contained patterns solve sub—problems in a divide—and—conquer fashion [Appleton00; Buschmann96, p.403]. Very few authors claim to have, or have indeed, constructed a complete pattern language. Alexander claims his 253—entry pattern language is complete for his domain, while Beck and Cunningham were among the first to create a pattern language within the field of computer science, containing only five pattern entries [Beck87]. According to Buschmann et al., other small languages from computer science include Crossing Chasms for connecting OO systems to relational database, and CHECKS by Cunningham for information integrity [Buschmann96, p.360]; in [Schmidt00, p.510-524], Buschmann et al. themselves claim to present a pattern language for middleware and applications in relation to concurrency and networking. By Alexander's definition, the general case is that pattern languages are very rare in any field. In computer science, catalogues and systems are much more common because of their lenient definitions. As we understand it, this is also a key issue pointed out by several critics of software patterns (see for example [Dominus02]): pattern languages are not used in computer science, merely the patterns themselves in a loosely organised fashion. Regardless, whether or not such languages indeed are pattern languages is open for debate, because there is no mathematical way to determine it.
3.7.1. "Gang of Four" Pattern System
In 1995, Gamma et al. published the "Design Patterns" book [Gamma95], describing twenty—three individual design patterns contained in a pattern system pertaining to OO, which popularised the use of patterns in computer science [Appleton00]. As explained in section 2.5.1.3, the "Gang of Four" design patterns describe concepts and structures beyond individual objects and classes up to the granularity level of refinement of OO sub—systems, customised to solve a general design problem in a particular context [Gamma95, p.3]. Below, table 3.4 lists the twenty—three "Gang of Four" design patterns from [Gamma95], including their classifications and relationships.
Gamma et al. classify the "Gang of Four" patterns in two dimensions according to Scope (Class and/or Object) and Purpose (Creational, Structural, or Behavioural) [Gamma95, p.10]. The Scope criterion identifies whether the pattern applies primarily to classes or objects. Class patterns deal with relationships between classes and their sub—classes. Object patterns are more dynamic, and deal with objects and their relationships, but almost all the patterns uses inheritance, and thus classes to some extent. Purpose is a problem—based criterion that classifies the "Gang of Four" patterns according to what they do. Creational patterns focus on the instantiation process of objects [Gamma95, p.81]; Structural patterns focus on how classes and objects are composed to form larger structures [Gamma95, p.137]; and finally Behavioural patterns focus on algorithms and assignment of responsibilities between objects [Gamma95, p.221]. Other types of problem—based classifications exist, for instance Concurrency patterns (see for example [Schmidt00]).
| Table 3.4 — "Gang of Four" pattern system | ||||||||||||||||
| Name | Description | Scope | Related Patterns | ||||||||||||||
| Creational Patterns | |||||||||||||||||
| Abstract Factory | Provide an interface for creating families of related or dependent objects without specifying their concrete classes [Gamma95, p.87]. | Object |
| ||||||||||||||
| Builder | Separate the construction of a complex object from its representation so that the same construction process can create different representations [Gamma95, p.97]. | Object |
| ||||||||||||||
| Factory Method | Define an interface for creating an object, but let sub—classes decide which class to instantiate. Factory Method lets a class defer instantiation to sub—classes [Gamma95, p.107]. | Class |
| ||||||||||||||
| Prototype | Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype [Gamma95, p.117]. | Object |
| ||||||||||||||
| Singleton | Ensure a class only has one instance, and provide a global point of access to it [Gamma95, p.127]. | Object |
| ||||||||||||||
| Structural Patterns | |||||||||||||||||
| Adapter | Convert the interface of a class into another interface clients expect. Adapter lets classes work together that could not otherwise because of incompatible interfaces [Gamma95, p.139]. | Class, Object |
| ||||||||||||||
| Bridge | Decouple an abstraction from its implementation so that the two can vary independently [Gamma95, p.151]. | Object |
| ||||||||||||||
| Composite | Compose objects into tree structures to represent part—whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly [Gamma95, p.163]. | Object |
| ||||||||||||||
| Decorator | Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub—classing for extending functionality [Gamma95, p.175]. | Object |
| ||||||||||||||
| Facade | Provide a unified interface to a set of interfaces in a sub—system. Facade defines a higher—level interface that makes the sub—system easier to use [Gamma95, p.185]. | Object |
| ||||||||||||||
| Flyweight | Use sharing to support large numbers of fine—grained objects efficiently [Gamma95, p.195]. | Object |
| ||||||||||||||
| Proxy | Provide a surrogate placeholder for another object to control access to it [Gamma95, p.207]. | Object |
| ||||||||||||||
| Behavioural Patterns | |||||||||||||||||
| Chain of Responsibility | Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it [Gamma95, p.223]. | Object |
| ||||||||||||||
| Command | Encapsulate a request as an object, thereby letting you parameterise clients with different requests, queue or log requests, and support undoable operations [Gamma95, p.233]. | Object |
| ||||||||||||||
| Interpreter | Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language [Gamma95, p.243]. | Class |
| ||||||||||||||
| Iterator | Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation [Gamma95, p.257]. | Object |
| ||||||||||||||
| Mediator | Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently [Gamma95, p.273]. | Object |
| ||||||||||||||
| Memento | Without violating encapsulation, capture and externalise an objects internal state so that the object can be restored to this state later [Gamma95, p.283]. | Object |
| ||||||||||||||
| Observer | Define a one—to—many dependency between objects so that when one object changes state, all dependants are notified and updated automatically [Gamma95, p.293]. | Object |
| ||||||||||||||
| State | Allow an object to alter its behaviour when its internal state changes. The object will appear to change its class [Gamma95, p.305]. | Object |
| ||||||||||||||
| Strategy | Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it [Gamma95, p.315]. | Object |
| ||||||||||||||
| Template Method | Define the skeleton of an algorithm in an operation, deferring some steps to sub—classes. Template Method lets sub—classes redefine certain steps of an algorithm without changing the algorithm's structure [Gamma95, p.325]. | Class |
| ||||||||||||||
| Visitor | Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates [Gamma95, p.331]. | Object |
| ||||||||||||||
The legends used to describe the pattern relationships indicate the type of relationship. We have deciphered the relationships by examining all the pattern descriptions, especially the Related Patterns element, as well as [Gamma95, f.1—1,p.9-13]. The relationships do not indicate that the patterns must be used together as illustrated, merely that they can be. They are by no means a formal specification of the "Gang of Four" relationships, but help provide an overview in the practical application. The Use and Used by legends typically indicates a strong relationship, often a "has—a" relationship corresponding to composition and/or delegation in compliance with the general "Gang of Four" themes as described in section 2.1.2. The Is a and Implemented by legends indicates an "is—a" relationship, corresponding to class—based inheritance or interface implementation. The Collaborates with legend indicates some form of collaboration between the patterns, for example that both can be used by in conjunction by other patterns; the term is broadly defined and could refer to a stronger relationship such as Used by depending on the actual application. The Creates and Created by legends indicates a special form of creational collaboration. Finally, the Alternative to legend indicates that alternative, but not identical, solutions to a problem exist; however, applying one pattern over an alternative one may generate considerable changes to the design.
3.8. Pattern Evolution
Individual patterns evolve over time, but so too can pattern catalogues, systems, and languages. This is of pivotal importance because the patterns must reflect their environment, which according to Alexander is constantly evolving.
3.8.1. Mining
Mining is the non—trivial art of discovering new patterns within systems in a given domain and describing them. This is a term originating in computer science, but Alexander present similar ideas. The general idea is that true patterns are discovered, not invented, due to the duality in the definition of a pattern as explained in section 3.1. Coplien states that patterns observed in an existing system may not be desirable. Some patterns are non—generative, descriptive, and passive, i.e. recipe—like, which is not good and do not lead to desirable results [Coplien, i.3]. Only good patterns should be mined for actual (re—) use, which can then help generate new systems that will contain the pattern traits. Such patterns are generative, prescriptive, and active; they are more than simple recipes.
Since patterns represents common best—practices to reoccurring solutions, the pattern naturally has to be found in more than one design. The Rule of Three simply states that any pattern must have been found in at least three real—world systems for it to be considered a valid pattern [PPR, p.RuleOfThree]. Gamma et al. state that none of the "Gang of Four" design patterns represents new or unproved designs, but that they are elements of some successful OO system, or part of the folklore of the OO community [Gamma95, p.2].
3.8.2. Anti—Patterns
Anti—Patterns focus on existing software failures in an attempt to understand, prevent, and recover from them [McCormick01]. The term and its meaning were originally coined by Brown et al. as a counterpart to design patterns [Brown98]. Since they represent specific pitfalls to avoid during software development, they can naturally be found within any imaginable area, for instance management, organisation, design, programming, etc. Anti—Patterns are described using structured formats and each description is based on existing (bad) solutions [McCormick01]. Anti—patterns are sometimes referred to as code smells.
Design patterns are often the "cure" for anti—patterns. They describe a solution that will remedy the problems inherent in the anti—pattern. Pattern mining is therefore closely related to anti—patterns: new patterns may produce commonly accepted design patterns that can be used to avoid common pitfalls, but on the other hand, overly or wrong use of design patterns may be an anti—pattern by itself. Rarely, design patterns can thus be the very "symptom" described by an anti—pattern. The optimal solution is to evolve from designs containing anti—patterns - well, preferably containing none - to designs utilising well—described design patterns without constructing new anti—patterns in the process.
|
Example 3.3 — The Layers pattern [Buschmann96, p.31] discussed in example 2.3 is a design pattern offering a solution to pitfalls described by the Big Ball of Mud [PPR, p.BigBallOfMud] anti—pattern [Buschmann96, p.29]. It offers structure instead of chaos. On the other hand, the Singletonitis [Vieiro06] anti—pattern describes overly or wrong use of the Singleton [Gamma95, p.127] pattern; it exists because the Singleton pattern exist, and designers using the Singleton pattern should be aware of this. Example 2.4 considered applying the Singleton pattern in the design of the described notification mechanism, specifically to ensure unique Delivery and Formatter factories. Forcing singleton objects into libraries may cause unforeseen runtime consequences, such as class loading issues in Java, but it may also cause undesirable behaviour, such as severely restricting how clients can use and combine factories. The latter may be fine, but the consequences must naturally be thought through. In any case, the evolution of the notification mechanism could even require refactoring causing less frequent usage of the Singleton pattern |
There is no precise checklist specifying what constitutes an anti—pattern, but [PPR, p.AntiPatternsCatalog] lists many commonly accepted anti—patterns. Nevertheless, functionality some people regard as anti—patterns, others do not; even more so, functionality some regard as patterns, others regard as anti—patterns! A simple example is invoking an overridden method in a super class from inside the overriding method in the sub—class, i.e. an extra tight coupling between a super and sub—class that must be enforced by the developer. In Java, finalizer chaining is an example of this: when overriding java.lang.Object.finalize(), the developer must ensure that the finalize() method in the super—class is invoked [Bloch01, p.22-23]. Fowler identifies this as the Call Super [Fowler05] anti—pattern because there is no way to guarantee that the sub—class will invoke the overridden method in the super class (as opposed to method combination, for example in CLOS [DeMichiel87]). However, according to Grand [Grand99, p.179], Beck identifies this as a design pattern called Extend Super, though with a slightly different context. As a practical example, Livshits has identified misuse of the Extend Super pattern in the Eclipse project, which corresponds to the situation described by the Call Super anti—pattern [Livshits05, p.1-2].
3.8.3. Proto Patterns
Ideally, a newly discovered and initially described pattern is called a proto pattern until its qualities and elements have been validated and acknowledged by others, if at all, for example at a PLoP conference. This is also a term originating in computer science. A proto pattern will be investigated to see if it is meaningful within its domain; if it describes the forces at play; if it has the required elements and qualities; if the Rule of Three is adhered to; etc. Even if a proto pattern is accepted as a valid pattern, there is no guarantee that it will ever be commonly used. Many patterns are left unused. This does not necessarily mean that they are not useful, though as a concept design patterns are often misused to denote anything that has the slightest touch of recognisability, but perhaps rather that their context and problem is too specific to be truly valuable. On the other hand, many so—called patterns have been published violating the needed elements and qualities, not to mention the Rule of Three, or representing a solution in which no forces are at play. They could also be passive as described by Coplien, not generating quality solutions.
Once a proto pattern has been established to represent a valid pattern, it is no longer considered a proto pattern. The problem is naturally "who" decides this. Furthermore, since Alexander describes patterns as being non—static, we claim they will always function as "prototypes" in form of their knowledge and descriptions. For example, the "Gang of Four" Command [Gamma95, p.233] pattern has at least spawned the "POSA" Command Processor [Buschmann96, p.277] pattern, and in the evaluation we even present a variant of the Command Processor pattern that might eliminate the need to use Composite [Gamma95, p.163] (or macro) commands (see section 8.3.2.3).
3.8.4. Piecemeal Growth
Catalogues can mature and evolve into pattern systems over time as well as systems can mature and evolve into pattern languages via a process Alexander calls piecemeal growth: patterns are applied in an ordered sequence of piecemeal growth, progressively evolving an initial architecture, which will then flourish into a "live" design possessing the QWAN (see also table 3.1). As patterns are applied by the means of piecemeal growth, applying one pattern provides a context for the application of the next pattern [Appleton00]. This implies that both the collection and the design will evolve; if an individual pattern evolves, it may thus affect the entire collection.
According to Appleton [Appleton00], Alexander explains that piecemeal growth is based on the idea of repair as opposed to traditional architectural development processes that are based on the idea of replacement. Traditional processes assume that each act of design or construction can be viewed in isolation, "perfect" at the time of construction. Alexander calls such processes large lump development. Piecemeal growth acknowledges that environments are continuously changing and growing in order to keep its use in balance. Appleton notes that there are similarities between piecemeal growth and spiral development processes involving prototyping and iterative/evolutionary development, such as XP, as well as large lump development and the Waterfall model [Appleton00]. As explained in section 2.2, iterative OOMs acknowledge that the design is not static, but dynamic in nature. By using design patterns sharing similar traits the design will be able to evolve more easily.
A decade ago, Buschmann et al. speculated that the development of complete software design pattern languages was an optimistic, but worthwhile goal [Buschmann96, p.422]. To this day, the goal has not been achieved, not even using the "Gang of Four" patterns as the system to evolve into a proper pattern language. Buschmann et al. estimate that the "Gang of Four" pattern system may cover as much as half of the general—purpose design patterns of its domain [Buschmann96, p.422], i.e. at the granularity level of a few number of cooperating classes. Even though the "Gang of Four" patterns are also over a decade old, no additions have been added to the system by the authors. Many other design patterns have been published since then, however, claiming to target the same domain as the "Gang of Four" patterns, for example the well—known "POSA" patterns. To our knowledge, no unified attempt has yet been made to combine the vast number of design patterns into a unified language, or even system. This does not mean that the "Gang of Four" pattern system is static, or has not evolved. As stated, many individual "Gang of Four" design patterns have spawned variants or other related patterns. Furthermore, variants of the system itself could also evolve, for example a system balancing the Multithreaded Safety force described by Lea [Lea93, i.12]. To handle this force explicitly, each "Gang of Four" pattern would have to be re—engineered, causing at least changes to the description and sample code, but perhaps also to the pattern it self.
3.9. Pattern Application
As any tool or method, design patterns must be used correctly, i.e. when the design warrants it. It is as simple as that. It is as difficult as that. Patterns cannot really offer any guarantees that the application design will be a successful one [Vlissides97, i.5], and a critical, or at least careful, approach to any pattern is warranted in our opinion. Usage is closely related to how design patterns are perceived; i.e., as a practical tool; formally; more abstract along Alexander's original ideas; or somewhere in between.
3.9.1. Usage
Several anti—patterns can help describe misuse of design patterns. The Cargo Cult [PPR, p.CargoCult] anti—pattern can explain the dangers of using design patterns without understanding why, and on a software engineering level, it can describe the dangers of following the procedures dictated by an OO Method (OOM) without understanding why. This is relevant for the evaluation in case the investigated "Gang of Four" patterns advocate the use of specific language features. The Golden Hammer [PPR, p.GoldenHammer] anti—pattern can describe the overuse of design patterns, i.e. applying patterns were they are not needed, perhaps adding unnecessary layers to the code (over—engineering). As a practical example, Livshits describes misuse of the Extend Super (or the anti—pattern Call Super) and Observer patterns in the Eclipse project [Livshits05, p.1-3].
At [PPR, p.DesignPatternsConsideredHarmful], these very issues are discussed, especially over—engineering. No conclusions are drawn, naturally, as the use and understanding of design patterns is the individual designer's prerogative, in part because of the lack of formalism. However, we do think that critics often neglect the fact that design patterns are more than recipes, especially concerning the "Gang of Four" patterns. A common misconception is what Vlissides calls "the belittling dismissal" [Vlissides97, i.2]: patterns are only seen as recipes containing jargon, rules, programming tricks, data structures, etc., without acknowledging important pattern aspects such as problem, context, teaching, and naming. The value of the "Gang of Four" vocabulary should not be underestimated because it is a powerful tool for communicating design issues [Vlissides97, i.4]. While the "Gang of Four" patterns may not be applicable for all contexts, the concepts and themes identified in section 2.1.1 and 2.1.2 can still be utilised, because designers familiar with the patterns should also be familiar with these themes and concepts.
Pattern usage is closely tied to the implementation. Another issue raised is whether the use of design patterns result in duplicate code within a system or not [PPR, p.PatternBacklash]. Some of the main design goals in any OO system are reuse, maintenance, and modification [WirfsBrock90, p.9]. The goals are reflected in the most important non—functional forces regarding OO development as defined by Buschmann et al., namely Changeability, Interoperability, Efficiency, Reliability, Testability, and Reusability [Buschmann96, p.404-410] (see also section 3.4). Ideally, functionality should be referenced, not copied [PPR, p.OnceAndOnlyOnce]. Duplication of code does not mix well with these principles and forces. Therefore, the principle in applying patterns can seem contradictory to the very forces the patterns should heed. General refactoring, pattern componentization, and language support are possible solutions to duplicate code problems. Componentization and language support are discussed in some detail in chapter 4.
3.9.2. Understanding
Dominus has a bleak, but practical and perhaps more realistic, view on software design patterns and their usage, and insists that software design patterns as described by the "Gang of Four" and many others are fundamentally different from Alexander's ideas of patterns and especially pattern languages [Dominus02]. According to Dominus, the "Gang of Four" idea is to discover existing design patterns (mining), and then program people to implement them habitually. Contrary to this, Alexander's pattern language help decide what should be designed, but does not dictate how to design anything; the user can decide what patterns will lead to a good design. Hence, Dominus concludes that the two approaches are completely different, representing two different meanings assigned to the term design pattern. The "Gang of Four" approach is much less profound and human, and he strongly advocates that the software pattern community needs to re—implement Alexander's ideas.
As we understand Alexander, we agree with the statement that software pattern collections really do not express the ideas set forth by Alexander concerning pattern languages, e.g. QWAN, order of unfolding, generativity, etc. We perceive design patterns as a valuable and practical tool to aid the design process, but one that do not generate fixed solutions. Ergo, we once again agree with Vlissides, who writes [Vlissides97, i.6]:
| The key to generativity is in the parts of a pattern dedicated to teaching — the forces and their resolution, for example, or the discussion of consequences. These insights are particularly useful as you define and refine an architecture. But believing that patterns themselves can generate architectures or anything else is definitely over the top. Patterns don't generate anything; people do, and they do so only if both they and the patterns they use are up to snuff. |
On the other hand, we think that software design patterns in practice generally try to express the ideas of forces and pattern elements, and to some extent pattern qualities. A testament to this is the large number of references to Alexander's writings on these exact topics, for example [Appleton00; Gamma95; Lea93; Lea00; PPR], but more importantly that the pattern formats commonly used all express these notions. Dominus seems close to performing "a belittling dismissal" [Vlissides97, i.2] of the "Gang of Four" patterns. We also think Dominus neglects the fact that Alexander's patterns really cannot be chosen completely at random because of the order of unfolding, including granularity. Because software pattern collections differ from Alexander's ideas, they rarely have such restrictions. The designer is still free to choose relevant design patterns, and should be able to decide how to implement them. In any case, even if the meaning of software design patterns differs from Alexander's notion, they can still be used (as Dominus also notes).
3.10. Summary
A software design pattern is a pattern related to the design of software systems, but patterns can be applied in different areas and fields. The term "design pattern" refers to a classification of software design patterns that can be used throughout the OOD phase for OO systems, targeting communicating objects and classes that are customised to solve a general design problem in a particular context. Design patterns thus rely heavily on OO concepts, and separate the principles from the implementation. Different languages can thus be used to implement the solution described by a given pattern.
The notion of a pattern is two—fold: a pattern is an abstraction of practical experience and basic knowledge, but it is also a literary description of this knowledge, written in a consistent format. The pattern describes the problem it solves as well as a solution to it; hence, the pattern can be applied for similar problems in other contexts. As such, design patterns are not invented, but discovered in existing solutions. Different formats exist, containing required pattern elements to describe different important aspects of the pattern functionality, such as a concise name, forces, related patterns, etc. A format traditionally uses natural language, illustrations, and examples as opposed to formal specifications. The naming of patterns allows designers and others to communicate architectural ideas in a high—level consistent language. Hence, human interaction is paramount in pattern application because patterns are not out—of—the—box reusable components; pattern application as described by Alexander requires interpretation and adaptation to apply in them in the design at hand. Within computer science, however, efforts are being made to include patterns as language features or implement them as reusable components. Not everything that can be written using a pattern format constitutes a valid pattern, because patterns must possess a certain set of qualities to ensure the overall quality of the design. The qualities are Abstraction, Composibility, Encapsulation, Equilibrium, Generativity, and Openness, and many of these qualities have similar constructs in OO.
A pattern can be an entry in a collection. A pattern catalogue is a collection of loosely and/or informally related patterns, while a pattern system is a cohesive set of related patterns described in a consistent format that works closely together. A pattern language can be viewed as a pattern system covering a complete domain with rules and guidelines, which explain how and when to apply its patterns to solve a problem that is larger than any individual pattern can solve. Patterns and pattern collections will evolve over time, reflecting knowledge gained through continued use and adaptation. Patterns can present solutions to known software failures that are recorded as anti—patterns, but unwise application of patterns may be an anti—pattern by itself. As patterns are implemented using a given programming language, the features of the language may influence the application and perhaps bring new insights to the pattern description. On the other hand, the pattern description may also dictate behaviour that has direct impact on the implementation.
Within the pattern community, there is some debate about what a design pattern is. Some people are followers of Alexander's ideas, which emphasise the human interaction, while others prefer more structural approaches in order to analyse and apply patterns. Pattern formalism tries to bring rigid structure to design patterns at the expense of human interaction. In this thesis, we try to apply the best from both worlds. We perceive design patterns as a valuable and practical tool to aid the design process, but one that do not generate fixed solutions. As any tool or method, design patterns must be used correctly: only when the design warrants it.
The "Gang of Four" design pattern system contains twenty—three design patterns classified in two dimensions: Scope and Purpose. The Scope criterion identifies whether the pattern applies to Classes and/or Objects. Purpose is a problem—based criterion that classifies the "Gang of Four" patterns according to what they do. Creational patterns focus on the instantiation process of objects, Structural patterns on how classes and objects are composed to form larger structures, and Behavioural patterns on algorithms and assignment of responsibilities between objects. The "Gang of Four" patterns are described using the "Gang of Four" format, using C++ and Smalltalk as example code, and we deciphered the pattern descriptions to clarify and label the relationships between the individual "Gang of Four" patterns. The "Gang of Four" patterns express the OO themes and concepts described in chapter 2. The concepts and C++ constructs used in the "Gang of Four" canonical pattern implementations will be used extensively in the evaluation as reference points for the features used in the Java 6 implementations.
| 5. | It is not that uncommon to hear a Danish engineer turned developer pondering: "Why is there not a ståbi for this problem?". But there often is - in form of a software design pattern. |
| 6. | Alexander's patterns can be viewed online at http://www.patternlanguage.com/leveltwo/patterns.htm. |
| 7. | The first "POSA" book uses the term pattern systems as almost a synonym for pattern languages as described by Alexander [Buschmann96, p.360-362], while the second book explicitly differentiates between systems and languages [Schmidt00, p.524-526]. |