Master's thesis


Magnus Kardell

Umeå University


Over recent years patterns have been drawing attention in the software community. Patterns capture knowledge from various parts of software developing. As the number of patterns increases the need to organize the patterns becomes more important. A classification scheme should organize patterns in a library and assist users in finding and storing patterns. This thesis concerns a classification of object-oriented design patterns. Developing a classification scheme involves finding useful criteria that should reflect natural properties of patterns. The thesis also contains a thorough survey of patterns and related topics.


TABLE OF CONTENTS ITABLE OF FIGURES IIIACKNOWLEDGMENTS IVINTRODUCTION VTHE CONCEPT OF PATTERNS 11. Construction architecture patterns 11.1 An architectural pattern example - Window Place 22. Software Patterns - an overview 32.1 A software design pattern example - Composite 4DESIGN PATTERNS 83. Criteria of a OO-design pattern 83.1 The matter of domain 93.2 The matter of paradigm 93.3 The matter of granularity 103.3.1 Architectural patterns Object-oriented architectural patterns 113.3.2 Idioms 124. The purpose of design patterns 134.1 Framework related approaches 134.1.1 Frameworks 134.2 General approaches 15DESIGN PATTERN APPROACHES COVERED 165. Gamma et. al - Design Pattern Catalog 165.1 Format 176. Coad - Object Models 186.1 Format 197. Comparison of approaches 19APPROACHES TO CLASSIFICATION 228. Gamma et. al 229. Buschman et. al 2310. Zimmer 2511. Coad 2712. Pree 28A CLASSIFICATION SCHEME FOR DESIGN PATTERNS 3013. Demands on a criterion 3014. Overview of the proposed classification scheme 31CLASSIFICATION OF DESIGN PATTERNS 3315. Activity - the root criteria 3315.1 Patterns in the categories 3315.2 Related criteria in other classifications 3415.3 Pros and cons 3416. Criteria for the design patterns 3516.1 Applies to 3516.1.1 Patterns in the categories 3616.1.2 Related criteria in other classifications 3716.1.3 Pros and cons of the criterion 3716.2 Purpose 3816.2.1 Patterns in the categories 3916.2.2 Related criteria in other classifications 3916.2.3 Pros and cons of the criterion 4116.3 Scope 4216.3.1 Patterns in the categories 4216.3.2 Related criterion in other classifications 4216.3.3 Pros and cons of the criterion 4316.4 Time to apply 4316.4.1 Patterns in the categories 4316.4.2 Related criteria 4416.4.3 Pros and cons of the criterion 4417. Criteria not chosen in my classification 4417.1 Structural aspects 4417.2 Structural mechanisms 45ADDITIONAL LIBRARY FUNCTIONS 4718. Abstraction 4719. Relationships 47CONCLUDING REMARKS 4920. Extending the classification scheme 4920.1 Patterns from other development phases 4920.2 Supporting domain dependent OO-design patterns 5020.3 Supporting architectural patterns 5121. The future of patterns 51REFERENCES 53APPENDIX A - DESIGN PATTERN CATALOG 56APPENDIX B - OBJECT MODELS 68TABLE OF FIGURESFigure 1: Class diagram of Composite. 5Figure 2: Structural diagram of Composite. 6Figure 3: Composite. 6Figure 4: Objectifier. 27Figure 5: Abstract coupling. 29Figure 6: Recursive structure. 29Figure 7: My classification scheme. 32Figure 8: Criteria for design patterns. 35Figure 9: Possible extensions of activity. 50

Table 1: Classification-scheme in the Design Catalog. 23Table 2: Design and classification patterns. 34Table 3: Patterns in the categories of Applies to. 37Table 4: Patterns in the categories of Purpose. 39Table 5: Patterns in the categories of Scope. 42Table 6: Design patterns in the categories of Time to apply. 43


I would like to thank Jürgen Börstler and myself in chronological order.


Right now I am applying a pattern. We may call it the “Writing a thesis pattern". If this thesis ever get ready this pattern has provided the solution. While the thesis is not ready it provides a problem. That is what patterns are all about. More formally the “Writing a thesis pattern" may be stated:

Problem: Writing a thesis that should pass.

Context: To make the thesis structural and comprehensible.

Forces: Time is running out and some concepts cause confusion.

Solution: Use the supervisors advice.

Of course this sample pattern is not the kind of patterns that I will investigate in this thesis. The “Writing a thesis pattern" concerns writing, this thesis concerns object-oriented design patterns; and furthermore this thesis is about finding a scheme to classify such entities. Such a classification would help us find patterns kept in a library. The library is intended to keep general and domain-independent object-oriented design patterns. The scheme should classify them into groups of related patterns. That is what it is all about. However, all these concepts must be explained and that is what I will do after the following survey.

In the first section "The Concept Of Patterns" I will explain the terms pattern and pattern languages and also present patterns from both construction architecture and software. In the second section "Design Patterns" I will define what characterize object-oriented design patterns and the purpose of using them. This involve discussions concerning topics such as domain dependency, granularity, paradigms and frameworks. In the third section "Design Pattern Approaches Covered" I will present the design patterns that I will use as material for my classification. In the fourth section "Approaches To Classification" I will present different approaches that has been made to classify design patterns. The fifth section "A Classification Scheme For Design Patterns" contains an overview of my proposed classification scheme and some aspects on useful criteria. The sixth and the seventh sections: "Classification Of Design Patterns" and "Additional Library Functions", describes my classification in detail. The last section "Concluding Remarks" provides some parting thoughts about possible extensions to my work and the future of design patterns in general.


This section will describe and exemplify the concept of patterns and pattern languages. Starting with patterns in construction architecture, which has had a large impact on patterns in software, and ending with a software design pattern. This to make the reader familiar with software patterns before further discussion in the subsequent sections. Bear in mind however that software patterns lack a uniform format and that this is only one approach among others which will be covered later on.

  1. Construction architecture patterns

Although this paper is about patterns in software engineering the concept of patterns is not a domain-specific issue. Patterns apply in many domains. In fact it was in the domain of building architecture that the concept of patterns was first introduced.

One of the first to propose the idea of using patterns was the building architect Christopher Alexander. Alexander found recurring themes in architecture, and captured them into descriptions (and instructions) that he called patterns. The term 'pattern' appeals to the replicated similarity in a design, and in particular to similarity that makes room for variability and customization in each of the elements 11.

Alexander defines, in his book “A Timeless Way of Building" 2, the term pattern as follows:

“Each pattern is a three part rule, which express a relation between a certain context, a problem and a solution.

As an element in the 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 pattern is, in short, at the same time a thing, which happens in the world, and the rule which tell us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing."

By using his patterns as elements Alexander developed what he called a pattern language. A pattern language is not a language in any strict sense. It merely uses the structure of a grammar. A pattern works on a context to transform it into a new context which is addressed by another pattern. In this language the patterns are ordered by their level of detail which also implies the order of when they should be applied. The level of detail ranges from patterns that describe how to split the world into nations to patterns that describes how to decorate and provide lightning in rooms 8,11.

  1. An architectural pattern example - Window Place

Alexander describes his patterns in natural language using a consistent format which contains the patterns name, the given context, the forces that act and the solution. Here is an example of a pattern:

Window Place 1:

“Everybody loves window seats, bay windows, and big windows with low sills and comfortable chairs drawn up to them. …A room which does not have a place like this seldom allows you to feel comfortable or perfectly at ease. …

If the room contains no window which is a “place", a person in the room will be torn between two forces:

  1. He wants to sit down and be comfortable.
  2. He is drawn toward the light.

Obviously, if the comfortable places--those places in the room where you most want to sit--are away from the windows, there is no way of overcoming this conflict. …

Therefore: In every room where you spend any length of time during the day, make at least one window into a “window place"."

  1. Software Patterns - an overview

Software patterns have a short history. In the early 1990's the software community began to show interest in the concept of patterns. The following years patterns entered the vernacular as a result of seminars, conference sessions and journal publications 5.

To categorize each pattern approach is well beyond this thesis scope. A fledging body of diverse literature on patterns has emerged. Rather than describing the similarities between different approaches I will instead point out some of the most significant differences between them. Today you will find patterns that:

Pattern approaches are not bound to some specific part of software development. You can find patterns in each activity. Patterns documented today range from those that concern requirement engineering to those that concern process management or software architecture. Some approaches also include several phases and are thus means for transformations.

Some approaches present stand alone patterns while other present patterns that relate to each other to make up a language or a system.

Some patterns describe problems that are more or less domain-specific. For example a pattern that describes how to use a database is far more specific than a pattern that describes how to create a complex object.

There are numerous forms of describing a pattern. Of course this depends on which type of problem the pattern addresses - a pattern that describes how to organize people to manage a software project will differ from a pattern that describes how to arrange a three-layered architecture. But there are also format differences in patterns that addresses similar problems.

In the subsequent sections the only domain that will be discussed are patterns in object-oriented design. Readers who are interested in patterns concerning other domains will find more than enough material in 5,7.

  1. A software design pattern example - Composite

As stated there are many different forms of patterns and it is impossible to give examples of all of them. Never the less I feel obliged to give the reader an example of a pattern to ease comprehensibility. In the subsequent sections I will define what kind of patterns that I will include in my classification - object-oriented design patterns. Therefore I have chosen a pattern from an approach that is the most thorough in that domain. The pattern example is from the book: Design Patterns: Elements of Reusable Design 3 by Gamma et. al. A pattern of Gamma et. al's format is up to 15 pages long so to keep it down I have excluded some sections.

Composite 3:


Composite objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.


Graphics applications like drawing editors and schematic capture systems let users build complex diagrams out of simple components. The user can group components to form larger components, which in turn can be grouped to form still larger components. A simple implementation could define classes for graphical primitives such as Text and Lines plus other classes that acts as containers for these primitives.

But there's a problem with this approach: Code that uses these classes must treat primitive and container objects differently, even if most of the time the user treats them identically. Having to distinguish these objects makes the application more complex. The Composite pattern describes how to use recursive composition so that clients don't have to make this distinction.

Figure 1: Class diagram of Composite.

The key to the Composite pattern is an abstract class that represents both primitives and their containers. For the graphics system, this class is Graphic. Graphic declares operations like Draw that are specific to graphical objects. It also declares operations that all composite objects share, such as operations for accessing and managing its children. The subclasses Line, Rectangle, and Text (see preceding class diagram) define primitive graphical objects. These classes implement Draw to draw lines, rectangles, and text respectively. Since primitive graphics have no child graphics, none of these subclasses implements child-related operations.

The Picture class defines an aggregate of Graphic objects. Picture implements Draw to call Draw on its children, and it implements child-related operations accordingly. Because the Picture interface conforms to the Graphic interface, Picture objects can compose other Pictures recursively.

The following diagram shows a typical composite object structure of recursively composed Graphic objects:

Figure 2 : Structural diagram of Composite.


Use the composite pattern when


Figure 3: Composite.




In this section I will define the criteria for an object-oriented design pattern. This to specify the material for my classification. A distinction will be made on specific criteria that involve the concepts of architectural patterns and idioms. I will also discuss what is believed to be the purpose with object oriented patterns. These purposes can be divided into two categories to which approaches relate.

  1. Criteria of a OO-design pattern

There exists no standardization of the term design pattern in the realm of object-oriented software development 9. The term design pattern is sometimes used to refer to any pattern concerning software architecture. To define the range of object-oriented design patterns in this thesis I will impose two constraints.

For a pattern to be a object-oriented design pattern I impose the following constraints:

The indent with this restriction may not be easy to comprehend at the moment but it will be evident later on. It is however inevitable for me to make this restriction because if every pattern in the diversity of patterns that exists should be considered into my classification it would lie way outside the scope of this thesis. I believe that these constraints separate patterns that should belong to other classifications. By analogy: if you are repairing your car you most likely look for spare parts at some local car-repair-shop and not in an aircraft station even though both places contain spare-parts. Likewise if you are entering the pattern library that uses my classification you are looking for patterns that passes this jurisdiction and no else. As a consequence the constraints separate patterns by matter of:

  1. The matter of domain

The second constraint imposes that an object-oriented design pattern should be domain independent. Equally stated: a domain independent pattern should be general enough to be applied in every domain. Patterns that do not match this constraint - domain dependent patterns - can originate from:

In some cases it is very difficult to decide whether a pattern concerns a specific application or not. Consider an object-oriented design pattern that tells you how to parse a language. Is this pattern specific to the domain of constructing compilers or can this pattern be applied to other situations ? In other cases it is easier -- for example a pattern that describes how to use a specific database.

Real-time, communication, and distributed systems are often event-driven and have multiple-control flow. In object-oriented design that often means creating objects that executes autonomously in their own threads of control - active objects. Moreover these systems may have objects spread over different address-spaces. These topics brings their own set of problems which deal with factors such as:

I will not include those domain-specific patterns in my classification. Even though some of the patterns from these areas build upon more general patterns (see Schmidt 14 ) it is never the other way around. A discussion about including domain-specific patterns in a classification is presented in the section "Concluding Remarks".

  1. The matter of paradigm

The first constraint imposes that the choice of paradigm is fundamental. Each paradigm has its own design patterns. An imperative design pattern could address a similar problem as an object-oriented design pattern but it would present a solution described in procedures and functions. The paradigm also specifies the scope of patterns. An object-oriented pattern relies on programming language features such as inheritance and encapsulation which could be patterns in other paradigms 3.

I will not include design patterns from other paradigms in this classification mainly of two reasons:

  1. The matter of granularity

The level of granularity is important as this affects both the problem that the pattern addresses and the solution it describes. Many pattern taxonomies divide patterns in software architecture by granularity ranging from architectural patterns to idioms.

  1. Architectural patterns

An architectural pattern addresses the overall structuring principle of a software architecture. Those patterns are often highly specific to the system they describe and the solutions these patterns express are in terms of subsystems. For example the ISO reference model for OSI is an instance of an architectural pattern where the communication subsystem is broken down into layers each of which performs a well defined service 20. This pattern is often referred to as layered architecture 12,16.

The purpose of architectural patterns is to impose a structure that 16:

In my classification I will not include architectural patterns. I believe that the relationship between what I refer to as design patterns and architectural patterns is to weak. This weakness is due to the facts that architectural patterns in general:

The main structure of a system is very closely related to the purpose of the system and the environment that system will be run on. See the previous discussion about the matter of domain.

In general an architectural pattern does not impose what language the system should be built with. Among the architectural pattern approaches that exists today no one states explicit that their patterns have relations to a specific paradigm. An exception to that is the approaches that implicit relate to the object-oriented paradigm by using the same terminology for describing architectural patterns and object-oriented design patterns. These approaches may contain architectural patterns that can be used as design patterns. I refer to those as object-oriented architectural patterns.

  1. Object-oriented architectural patterns

There are examples of patterns presented as architectural patterns that also can be interpret as design patterns. They usually originate from approaches that also contains object-oriented design patterns. An example of this can be found in the approach by Buschman et. al 12,23. They present the Model-View-Controller pattern as an architectural pattern that is used to model a system into three classes (components) of large granularity. The controller class is responsible for responding to user input and notify the other classes. The model-class contains the domain-specific data and the view-class is responsible for displaying it. The purpose of this pattern is that the views and the controller should be unaware of the domain-specific model class --this to make it easy to separate and reuse domain-independent classes. However the pattern does not necessarily have to define an overall structure of a system. It could as well address objects of a smaller granularity and thus be used as an object-oriented design pattern.

There is yet another reason to why I do not include architectural patterns in my classification. This aspect may not be understood right now but I will give it anyway. In my classification I will use the work in classifying relationships between patterns by Zimmer 13. By using relationships between patterns we automatically find patterns of different granularity as a pattern that uses many other patterns has a higher granularity then the other. This aspect will be further discussed in the section "Additional Library Functions".

Examples of architectural patterns can be found in 5,7.

  1. Idioms

Idioms are patterns that are programming language dependent. For example a design pattern that concerns managing of dynamic objects lifetime is useful when designing for languages that lack garbage-collection but superfluous regarded to languages that support it.

The principal goals of idioms are 9:

I will exclude idioms in my classification though they are quite close to design patterns. The reason is that idioms:

As there are numerous object-oriented languages that differ from one another in certain aspects this language factor is hard to define. For example, there are design-patterns that uses multiple inheritance. As there are object-oriented languages that do not support multiple inheritance all those patterns should be considered as idioms. Further investigations of differences between object-oriented languages would bring up more aspects that should contribute to the factor. I believe that this work would be rather useless as it probably would result in defining a unique factor for each language.

You will find a further discussion about architectural patterns and idioms in the section "Concluding Remarks".

Examples of idioms can be found in 5,7.

  1. The purpose of design patterns

The key purpose of design patterns is reuse of experience. When software developers build new systems they are not likely to invent a unique design. Probably they are, without knowing it, using techniques that has been used before but not documented. Instead of reinventing all their design they should be able to imitate already invented designs. This is where design patterns come in. A design pattern is a documented solution to a problem that has been proven to work in a certain design situation. This means that patterns can provide:

A more abstract design vocabulary will help developers communicate more efficient. Consider for instance the design pattern example (see page 4). Even if you have not noticed, it has extended your vocabulary and you are now able to refer a quite complex collection of classes and relationships as a “Composite". This also makes documenting and learning systems easier since we are able to use this more abstract vocabulary. Design patterns also provide means for designing and re-designing systems. Developing object-oriented systems is usually a process that starts with an analysis-phase that evolves into a design-phase. The analysis-phase results in a model that is re-worked during the design-phase to make an implementation model, which has to take into consideration additional details such as programming language, class libraries and so forth. In this design re-work you should be able to identify where a pattern could be applied and then adjust the model using the pattern as a guide that should lead you to an implementation.

There are two major kinds of purpose that design pattern approaches have:

  1. Framework related approaches

  1. Frameworks

In the past software developers relied on general-purpose class libraries as the source of reusing code. These libraries often contained domain-independent modules such as stacks, queues and lists. Applications reused those components by creating object instances and invoking their methods. Even though such class-libraries achieved reuse their basic drawback was that the scope of the reusable classes were too narrow to significantly reduce the amount of application code that had to be developed manually. To achieve a higher level of reuse class-libraries has evolved into frameworks 5,10.

Lewis et. al 10 defines a framework as:

“An object-oriented framework provides both static and dynamic parts of an object-oriented program. A framework is an object-oriented class hierarchy plus a built-in model which defines how the objects derived from the hierarchy interact with one another…frameworks are specialized for a narrow range of applications, because each model of interaction is domain-specific, e.g., designed to solve a narrow set of problems.".

The main difference between class-libraries and frameworks is that a framework manages the flow of control in an application. Instead of writing code that calls the reusable components an application developer writes code that gets called from the framework. A framework supplies both components and behaviour and can be viewed as a semi-complete application. The intentions of a framework is not to be reused by all kinds of applications - it is supposed to be highly reused by a narrow domain of applications. This makes a framework much more domain-specific then a class-library 5.

Developing a framework is complicated. The developers must identify the parts of the framework that a user would like to change. These parts should be made variable. For example, in a common framework such as the Document-View framework it should be easy for the user to add and remove views referring to a document. However all parts of a framework should not be variable. This would increase the level of knowledge that a user must have to use the framework and make the framework inefficient. For example a user of the Document-View framework should not have to define message-passing handlers of his/her own.

Thus there is a trade-off between flexibility and stability:

The main purpose of framework related design pattern approaches is to describe the design of a framework and its individual classes without revealing implementation details. Patterns act as abstract design descriptions which can constitute a vehicle for communicating in an efficient way. As a result patterns can contribute to:

Works in this area has been done by Pree 9, Johnson 8 and various authors of articles in 5,7.

  1. General approaches

A general approach does not highlight frameworks as the primary goal for the use of design patterns. Design patterns are presumed to apply to any application. At the extreme design patterns become competitors to frameworks in the way that both strive to achieve reuse -- design patterns by means of textually describing experience and frameworks by reuse of code.

These approaches emphasise that design patterns are:

This thesis is a part of this kind of approach. This view upon patterns means that patterns should be documented, stored and later reused in software development. This is where the use of a general design pattern library would be most beneficial. Developers of object-oriented software facing a specific problem should be able to easily find a matching pattern that provides a solution from a library. As such a library would contain a diversity of specific patterns a good classification is of vital importance. As a consequence, the material that I will use in my classification are from general approaches. These approaches are presented in the next section.


The approaches that I will consider from here and on present patterns that meet the criteria I defined earlier (see page 8). In other words they present design patterns with the following characteristics:

There are some approaches that I have been forced to exclude even if they present design patterns with the characteristics above. The reasons are:

Some approaches present only a limited set of their patterns. As patterns is a new concept many developers are in the beginning of their work.

There exists a wide variety of pattern forms. To make a useful classification the patterns formats must be somewhat similar. I have included approaches that describes patterns using a format similar to Gamma et. al 3 which is the most recognized.

I have chosen the approaches by Gamma et. al 3 and Coad 4. They both encompass enough material and their pattern form is somewhat similar. Regarding a classification the differing pattern form will introduce new aspects as the most thorough works at present on classifying design patterns only includes patterns that draw on Gamma et. al's form.

  1. Gamma et. al - Design Pattern Catalog

The book Design Patterns: Elements of Reusable Object-Oriented Software 3 was released in 1995. The authors are somewhat design-pattern pioneers in the way that their form of pattern has been adapted by most of the design pattern approaches presented today. Compared to other approaches their pattern form is very thorough. The book has a catalog-form and contains 23 patterns described uniformly using an informal language. Even though their approach is of general purpose it has a close connection to frameworks. Many of their patterns are used in such architectures. As a consequence many patterns address how to achieve flexibility. This is not necessarily a contradiction to a general approach however as flexibility is preferable in any application.

You will find a selected portion of the patterns in appendix A.

  1. Format

All the patterns in 3 are described by means of informal text and graphic diagrams in OMT notation. Each pattern is presented using a consistent format with the sections:

The name of the pattern and its classification.

A statement to explain:

Other names for the pattern.

A scenario that illustrates a design problem and how the class and object structures in the pattern solves the problem.

A statement that describes:

A graphical representation of the classes in the pattern and the interaction

between objects.

The classes and/or objects participating in the design pattern and their responsibilities.

How the participants collaborate to carry out their responsibilities.

A statement to answer:

A statement that answers:

Code fragments that illustrate how you might implement the pattern.

Examples of patterns found in real systems.

A statement that answers:

  1. Coad - Object Models

The book Object Models: Strategies, Patterns, & Applications 4 was released in 1996. The purpose of the book is to teach people how to build object models. In contrast to Gamma et. al 3 this is not a design pattern approach alone. Coad 4 describes five applications built by using 31 design patterns with the aid of 148 entities of another concept called - strategies.

These strategies can be viewed as plans of actions on how to build object models. They present guidelines on how to:

The major part of the strategies resembles patterns for analysis presented by Kerth 18 and Whitenack 17. What differs from these is that Coad's strategies are strongly connected to Coad's own object-oriented design method based on model-components. The 31 patterns that Coad presents are referred to as object-model patterns. They serve as templates of objects with stereotypical responsibilities and interactions. Compared to the strategies the patterns are standalone quantities, that is, they do not refer to Coad's model-components and can be used in developing object-oriented software regardless of design method .

You will find a selected portion of the patterns in appendix B.

  1. Format

Each pattern except the fundamental pattern is described by means of informal text and a graphic diagram in Coad Notation using a consistent format:

The name is a combination of the names of the objects involved in the pattern.

The category of patterns that the pattern belong to.

Notation that shows what messages the participating objects typically call each-other with.

Examples of real-world modelled objects that the pattern could apply to.

Other patterns that this pattern could be combined with.

  1. Comparison of approaches

The main difference with Coad's approach compared to Gamma et. al's approach is that Coad involves topics that lie outside the design phase. As mentioned earlier Coad's approach includes strategies which are topics that belong to the analysis phase. Further more the majority of Coad's patterns address how to model the world into objects and classes - an activity commonly termed as classification. This affects the patterns form. The main differences between Coad's and Gamma et. al's format are:

The objects in Coad's patterns have stereotypical responsibilities; they contain names of operations and variables that only serve as a guide to find the responsibilities that the objects in an instance of the pattern can have. This makes the patterns more of templates in the way that most of the patterns only suggest a solution not provide one. Patterns from Gamma et. al only includes operations and variables that has a functional role in the pattern. This makes Coad's pattern format much less thorough than Gamma et al's because Gamma et. al's patterns provide information on how to implement the patterns. Coad's patterns lack that information.

It may seem that these differences between patterns of Gamma et. al's form and Coad's form are too substantial to motivate storing these patterns together in a common library. I believe that this is not necessarily the case. If the goal was to unify the pattern forms this may be done. Differences such as Coad's strategies, which adds additional information to some patterns, could be added as a topic in each pattern resulting in a new format. However there is no need to unify the pattern forms. If they are separated into different sub-categories in a classification they could keep their differing form.

This would yield a separation of the design-phase into two sub-phases: classification and design. In the classification phase an object model is established which then is refined in the following design phase. This is also the action that I have taken in my classification where the sub-phases, classification and design, reflect the criterion "activity". This will be further discussed in the sections concerning my classification.

Eventually there are some patterns from the two approaches that are similar:


This section describes current approaches to classify object-oriented design patterns. You will notice that almost all of these approaches have used the patterns from the Design Catalog 3 or patterns with similar format as material. First I present the classification that Gamma et. al uses in the Design Catalog 3. Then I present the classification used by Buschman et. al 12 in their work on developing a system of patterns. After that I present Zimmer's 13 classification of relationships between patterns from the Design Catalog 3. Finally I have included Pree's 9 structural view upon design patterns.

  1. Gamma et. al

Gamma et. al 3 classify their own patterns by two criteria:

The criterion purpose should reflect what a pattern does. According to Gamma et. al there are three categories of purpose:

Patterns belonging to the creational category concern the process of object creation. Patterns belonging to the structural category deal with the composition of classes or objects. Patterns belonging to the behavioural category characterize the ways in which classes or objects interact and distribute responsibility.

The criterion scope specifies whether a pattern applies primarily to classes or to objects. There are two categories of scope:

Patterns belonging to the object category deal with object relationships, which can be changed at runtime and are more dynamic. Patterns belonging to the class category patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static - fixed at compile time.

A pattern can only belong to one category per criterion. Combining their two criteria yields :

Defer some part of object creation to subclasses.

Defer some part of object creation to another object.

Uses inheritance to compose interfaces or implementations.

Describes ways to compose objects to realize new functionality.

Use inheritance to describe algorithms and flow of control.

Describes how a group of objects co-operate to perform a task that no single object can carry out alone.

Table 1 shows the patterns from 3 and their classification:

Factory Method
Adapter (class)
Template Method
Abstract Factory
Adapter (object)
Chain Of Resp.

Table 1 Classification-scheme in the Design Catalog.

  1. Buschman et. al

The approach by Buschman et. al 12, 23 presents patterns of a form that is similar to Gamma et. al's. They classify design patterns by three criteria:

The criterion functionality reflects what particular functionality the pattern serves as a template for. Buschman et. al distinguishes four categories of functionality:

Patterns belonging to the category creation specify how to create particular instances of complex recursive or aggregate object structures. Patterns belonging to the category communication describe how to organize communication between a set of collaborating objects that may be remote or independently developed. Patterns belonging to the category access describe how to access services and state of shared or remote objects in a safe way, without violating their encapsulation of state and behaviour. Patterns belonging to the category organizing the computation of complex tasks specify how to distribute responsibilities among cooperating objects in order to solve a more complex function or task.

The criterion structural principles reflects certain architectural principles that patterns rely on. Buschman et. al distinguish four categories:

Patterns belonging to the category abstraction provide an abstract or generalized view of a particular entity or task in a software system. Patterns belonging to the category encapsulation encapsulate details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Patterns belonging to the category separation of concern factor out specific responsibilities into separate objects or components to solve a particular task or provide a certain service. Lastly, patterns belonging to the category coupling and cohesion remove or relax the structural and communicational relationships and dependencies between otherwise strongly coupled objects.

In contrast to the classification by Gamma et. al, a pattern can belong to more than one category per criterion. Buschman et. al present a classification scheme of their patterns in 12. But since only a few of the involved patterns are described thoroughly I do not include this scheme here. This lack of material is also the reason why this approach is not covered among the approaches in the previous section.

  1. Zimmer

Zimmer 13 classifies the relationships between Gamma et. al's patterns 3. As the starting point Zimmer uses the relationships that Gamma et. al describe in each pattern's "Related Patterns" section. These relationships address a wide range of issues from “the pattern uses another pattern in its solution" to “the pattern is similar to another pattern in constructing object structures".

Zimmer focuses on the problem and solution aspects of these relationships and divides the relationships into three categories:

When building a solution for the problem addressed by X, one sub-problem is similar to the problem addressed by Y. Thus the solution of Y represents one part of the solution of X.

This relationship differs from the previous one in that the usage of Y is by X is optional - some variants of X may use Y; others do not.

X and Y address a similar kind of problem.

By arranging the patterns along these relationships Zimmer identifies three different layers and identifies these as:

Figure 4 : Arrangement of design patterns into layers.

Figure 4 illustrates the relationships and layers:

The pattern Objectifier is a pattern that Zimmer found while doing his classification. As can be seen in the figure below the pattern is related to several other patterns. Zimmer points out that Objectifier is a generalization of those patterns which objectify behaviour. Figure 4 shows the structure of Objectifier:

Figure 4: Objectifier.

  1. Coad

As described earlier Coad's approach differs from Gamma et. al's in many ways. This is also true in aspect of classification. Coad neither stress the importance of a classification nor does he describe his organization of patterns in a thorough manner. The following description of Coad's classification may therefore be incomplete.

Coad 4 organizes his patterns around one pattern that serves as a template for other patterns that are divided into families.

This pattern serves as a template for all other patterns.

These patterns all have a transaction player or have players that commonly play with a transaction player.

These patterns interconnect with other patterns.

These patterns all have a plan player or have players that commonly play with a plan player.

Interaction patterns are patterns that describe object-interaction. Coad states that these patterns should be used to overlay on players in other patterns.

A further discussion about Coad's “classification" will be found in the sections concerning my classification.

  1. Pree

Pree's work 9 can be used to classify design patterns by structure. Even though Pree's aim with his work is to use patterns for developing frameworks Pree classifies patterns from various approaches in his book Design Patterns for Object-Oriented Software 9. I have sorted out all categories from the book that encompasses patterns from the approaches presented in the previous section, that is from Coadand Gamma et. al 3.

Pree divides those patterns from a structural point of view into the following categories:

Patterns that encompass primarily the basic modelling capabilities in object-oriented languages.

Patterns that describe how a group of classes supports the structuring of software systems.

Patterns that allow recursive building of hierarchies. The concept is when a subclass has a reference to itself or to a superclass. See Figure 6.

Patterns that are based on abstractly coupled classes. The concept of abstract coupling is when an object has a reference to an abstract class. See Figure 5.

Patterns that are related to the Model-View-Controller framework

Figure 5: Abstract coupling.

Figure 6 Recursive structure.


In this section I will present my classification scheme. This to make the detailed presentation of the classification in the next section more comprehensible to the reader. Before I present the scheme I will define and discuss some characteristics that a criterion in a design pattern classification should possess.

  1. Demands on a criterion

A criterion should reflect a natural property of a pattern. It should divide patterns into different categories each reflecting a specific property. For example, a possible criterion for classifying fruits could be “shape". This criterion would divide fruits into categories such as “spherical" and “cylindrical". A useful criterion for pattern classification should possess certain qualities. It should:

A countable criterion defines a countable number of categories.

A conceptual criterion defines categories that are conceptual subsets of the criterion.

A strict criterion defines incompatible categories. A pattern should only belong to one category of a criterion.

An universal criterion defines categories for all patterns. This enforces that it should not only contain existing patterns but also unwritten ones.

A specific criterion defines specific categories. Specific categories provide more detailed information to the user of the classification scheme.

Users of a classification scheme should find it easy to learn and use. A criterion should reflect a property that users understand.

A regular criterion defines categories that contain an equal number of patterns. This to avoid large categories which makes it harder to find a specific pattern.

A useful criterion should possess all the listed qualities but also be suitable in many situations. The criterion should reflect a concept that is always relevant to users of the classification scheme.

  1. Overview of the proposed classification scheme

In my classification there is one criterion that is superior to all other. It acts as the root in the classification scheme (see Figure 7) and defines two categories which will be treated differently. As mentioned earlier (see page 19) this criterion is activity and its two categories are classification patterns and design patterns.

For the design patterns I propose a classification by four different criteria:

These criteria will all be explained and discussed in the next section together with criteria that I have chosen not to include in my classification.

The classification patterns are not investigated in detail in this thesis. Instead of using a classification scheme I propose a search-tool based on what entity the pattern are a template for:

The concept of abstraction are discussed in the section Additional library routines together with an investigation of relationships between patterns in the library.

Figure 7 shows the classification chart with each criterion and its categories:

Figure 7: My classification scheme.


In this section I will explain and discuss the root-criterion activity and each criterion in the classification scheme for the design patterns. For each criterion I will present its categories and discuss its pros and cons. If the criterion has been used in any of the classifications presented in the section "Approaches to classification", I will discuss any differences or similarities. I will also discuss why some criteria presented in the section "Approaches To Classification" are not used in my classification.

  1. Activity - the root criteria

The criterion activity reflects in what activity a pattern should by applied and forms the root in my classification scheme. The criterion has two categories:

Patterns that belong to the category classification are patterns that act as templates on how to model the world in a classification activity. They do not primarily work in terms of objects and classes and deal with implementation issues but at a higher abstraction level and in terms of real world entities.

Patterns that belong to the category design are patterns that provide a full solution. They deal in terms of lower abstraction like objects, state, interfaces and so forth. The activities during a design phase are to refine and rework the design model.

  1. Patterns in the categories

Classification Patterns Design Patterns
Transaction patterns (Coad)All patterns from Gamma et. al
Plan patterns (Coad)Interaction patterns (Coad)
Aggregate patterns: (Coad)
Table 2 Design and classification patterns.

Table 2 reflects the differences between Gamma et. al's and Coad's patterns. All of Coad's patterns except the ones that Coad refers to as interaction patterns belong to the classification category. This is my interpretation but Coad 4 states this distinction implicit in the definition of the interaction family, when he states that patterns in this family should overlay other patterns. That is, these patterns should not be used as templates in making an object model but rather as means of refining an already existing model. This corresponds to my definition of classification and design patterns on page 33.

Note also that the patterns in the two categories differ in format. The exception is Coad's interaction patterns uses a classification pattern format. However when I further classify the design patterns I will exclude Coad's patterns because of their less thorough format which do not provide enough information for a classification by the criteria that I will use. This is no drastic limitation as Coad's interaction patterns are similar to patterns from Gamma et. al (see page 19).

Another pattern that I have excluded from the design category are Gamma et. al's Interpreter. I believe that Interpreter is a domain dependent pattern and its solution do not speak in the terms that defines a design pattern (see page 8).

  1. Related criteria in other classifications

The criterion activity is not found in any of the covered approaches to classification.

  1. Pros and cons

I believe that this criterion is useful. It is conceptual, easy to understand and it is specific. A user of the pattern library should know which activity he or she is currently up to and find a pattern that suits. A user should get aid in building a design model by applying classification patterns and then further establish responsibilities and collaborations between objects in the model by applying design patterns. The criterion is not complete as there are more activities involved in developing software. This will be discussed in the section Concluding Remarks.

  1. Criteria for the design patterns

The criteria that I use to classify design patterns are applies to, purpose, scope and time to apply. These are orthogonal to each other. Figure 8 shows the classification scheme.

Figure 8 : Criteria for design patterns.

  1. Applies to

The criterion applies to reflects what entity the pattern should be applied to. The criterion is closely related to the criterion purpose (see page 38). Applies to defines three categories:

Patterns that belong to the category object are applicable on an object. For example the pattern Decorator adds functionality to an object and the pattern Memento stores the state of an object.

Patterns that belong to the category object-families are applicable on a group or set of objects that not necessarily need to be related by inheritance. For example the pattern Mediator defines communication between a set of objects and the pattern Facade defines an interface for a set of objects.

Patterns that belong to the category related object-families are applicable on a group or family of objects where some or all objects are related by inheritance. For example the pattern Abstract Factory varies the instantiation of related families and the pattern Composite provides a common interface to a set of related objects.

It would be possible to define sub-categories to these categories. Structures such as lists or queues can be sub-categories of the object-family categories. I have though decided to stay at this level of detail because the patterns do not imply any greater detail.

  1. Patterns in the categories

ObjectObj-families Related Obj-families
BuilderFacade Abstract Factory
Factory MethodMediator Composite
PrototypeObserver Bridge
SingletonVisitor Flyweight
AdapterCommand Chain of responsibility
DecoratorTemplate Method
Table 3 Patterns in the categories of Applies to.

  1. Related criteria in other classifications

A similar criterion is not used in any of the covered approaches to classification.

  1. Pros and cons of the criterion

These are basic concepts in object-oriented design and should be familiar to every software developer.

The categories are not very specific. As stated they can be further refined.

The categories are strict as they are strictly separate by definition.

The categories are conceptual but at a high abstraction level.

The categories low specifics make them countable.

As the categories have low specifics this provides universality.

The regularity are, regarding the material classified, not perfect. I imagine that the category object-families will contain fewer patterns than the category related object-families because inheritance is common in object-oriented design.

The criterion is very useful especially combined with the criterion purpose. A user of a pattern library most likely knows what kind of entity he or she would like to apply a pattern to. For example if the user wants to instanstiate an object or families of related objects, add functionality to an object or to a family of related objects or define communication between a set of related or unrelated object-families.

As stated the criterion is orthogonal to purpose and the only drawback is that communication cannot be applied to an object. The other categories of purpose can apply to all the categories of applies to.

  1. Purpose

The criterion purpose reflects what purpose a pattern has, originating from the view of an entity. The criterion has seven categories:

Patterns that belong to the category interface are patterns which are concerned with the interface of an entity. An entity's interface can for example be conformed as in the Adapter pattern.

Patterns that belong to the category functionality are patterns which are concerned with what functionality an entity has. An entity's functionality can for example be added as in the Decorator pattern and varied as in the Strategy pattern.

Patterns that belong to the category state are patterns which are concerned with the state of an entity. The state are the dynamic and static values of an entities instance variables. An entity's state can for example be saved as in the Memento pattern and varied as in the State pattern.

Patterns that belong to the category communication are concerned with how entities communicate. The flow of communication can be defined as in the Observer and Chain of Responsibility patterns.

Patterns that belong to the category access are concerned with how an entity can be accessed. The way to access an entity can be defined as in the Proxy pattern.

Patterns that belong to the category physicality are concerned with how an entity is stored. Entities can for example share storage as in the Flyweight pattern.

Patterns that belong to the category instanstiation are concerned with how an entity is instantiated. Instantiation can for example be varied as in the Builder pattern.

  1. Patterns in the categories

Instantiation InterfaceFunctionality
Abstract FactoryFacade Decorator
Factory MethodComposite Visitor
BuilderAdapter Strategy
PrototypeBridge Template Method
ProxyMemento Chain of Responsibility
IteratorState Mediator
Table 4 Patterns in the categories of Purpose.

  1. Related criteria in other classifications

The criterion purpose is used with a similar definition in the classifications by Gamma et. al 3 and Buschman et. al 12. I will compare these two definitions of purpose before I compare them to my interpretation.

The classification by Gamma et. al 3 identify three categories of purpose (see page 22):

The classification by Buschman et. al 12 identify four categories of purpose (see page 23):

It is difficult to compare these two interpretations. The two classifications have been made using own material and patterns from other approaches are in general not included. Thus conclusions on how to interpret the definitions of the categories from each classification must be drawn independently.

I have compared the two classifications by the examples of similar patterns that have been classified by both approaches:

Belongs to the category creation in both Gamma et. al's and Buschman et. al's classification.

Belongs to the category structural in Gamma et. al's classification. Belongs to the category access in Buschman et al's classification.

Belongs to the category behavioural in Gamma et al's classification. Belongs to the category access in Buschman et. al's classification.

Belongs to the category structural in Gamma et al's classification. Belongs to the category access in Buschman et. al's classification.

Belongs to the category structural in Gamma et al's classification. Belongs to the category communication in Buschman et. al's classification.

The only conclusion that can be drawn from this comparison is that the category creational seems to be equally interpreted in both classifications. The other categories from the two classifications can not be used together or unified due incompatible interpretations.

The difference between my interpretation of purpose compared to Buschman et al's and Gamma et. al's is that I define categories of purpose based on entities and what characteristics a such possess. My interpretation of purpose is made to overcome the conceptual weaknesses that I believe both these approaches have. I believe that when a user of pattern library needs a pattern he or she is at some starting point. That is, they may have an entity that they want to adjust or refine by applying a pattern. A user most likely knows what he or she needs the pattern to do and can identify the patterns purpose - be it add some functionality to the entity or adjust its interface to make it compatible with some other entity.

A comparison of my interpretation with the other approaches will be included in the discussion of pros and cons below.

  1. Pros and cons of the criterion

My categories are based on entities and what characteristics a such possess.

This makes the criterion conceptual. This is an improvement with regard to both the other interpretations of purpose. The categories organizing the computation of complex tasks and access defined by Buschman et. al are not conceptual subsets of purpose. Also the categories structural and creational defined by Gamma et. al are not conceptual subsets of purpose.

I believe that my categories are quite specific. Compared to the other interpretations of purpose mine is more specific. For example a category like behavioural is imprecise because it can comprise state, functionality and communication to some extent.

My interpretation of purpose is from the viewpoint of an entity with a countable number of characteristics. This should ensure that the criterion has the same quality.

I believe that my categories are strict. The improvement here is regarding the classification of Buschman et. al. which allows a pattern to be contained in more than one category of a criterion.

The criterion is useful as it mirrors the core of a pattern. A pattern for design provides a solution to a specific problem and purpose defines categories that correspond to whereas the problem and solution lie. The conceptual qualities also improve the usefulness.

As can be seen in Table 4 the criterion is quite regular.

From the material that I have used and the interpretation that I have made there is nothing that contradicts the criterion being universal.

It is easy to understand that a pattern has a purpose for a user that is a bit familiar with patterns. A user that never have seen or heard of patterns may find it more difficult. The conceptual qualities should however improve the comprehension.

  1. Scope

The criterion scope reflects whether a pattern provides a solution that can be changed at runtime or not. It has two categories:

Patterns that belong to the static category provide solutions that can not be changed at runtime. For example the pattern Factory Method provides a solution that is static.

Patterns that belong to the dynamic category provide solutions that can be changed at runtime. For example the pattern Abstract Factory provides a solution that is dynamic.

  1. Patterns in the categories

Static Dynamic
Factory MethodAll other patterns
Adapter (class)
Template Method
Table 5 Patterns in the categories of Scope.

  1. Related criterion in other classifications

The definition of scope is similar to Gamma et. al's definition. The difference is that I just focus on if the pattern has dynamic or static solution. Gamma et. al's interpretation also embodies structural aspects implicit by reflecting if the pattern uses inheritance (class) or not (object) (see page 22). Structural aspects on patterns will be discussed further in the section containing criteria that I have excluded from my classification. Despite this difference the outcome of both our classifications are identical. Compare Table 5 to Table 1.

  1. Pros and cons of the criterion

These are basic concepts and should be familiar to every software developer.

The categories meet these demands as there are only two outcomes.

The criterion is not regular as there are far more dynamic patterns than static. However, from the perspective of a software developer this is good, as a dynamic system is preferable.

The criterion is useful but not as much as the criteria purpose and applies to. Scope does not identify patterns it just exclude patterns with undesired solution qualities.

  1. Time to apply

The criterion time to apply reflects when a pattern should be applied. The criterion has two categories:

Patterns that belong to the category building should be applied when building a new system.

Patterns that belong to the category reusing should be applied when redesigning an already existing system.

  1. Patterns in the categories

AdapterAll other patterns
Table 6: Design patterns in the categories of Time to apply.

  1. Related criteria

This criterion is almost identical to the criterion activity. The reason that I split these similar criteria is that I do not want the root criteria activity to be unbalanced. This would be the result if reusing were added as a category to activity, since reusing only contains one pattern. If, in the future, more reusing-patterns should emerge such an action would be preferable.

  1. Pros and cons of the criterion

These are basic concepts of object-oriented design.

The categories meet these demands as there are only two outcomes.

The regularity is, regarding the material classified, low as there is only one pattern in the reusing category. There may be more in the future though.

The criterion is useful as the patterns for reusing and building have different aims. The pattern for reuse: Adapter, should only be used when reusing a system as an alternate solution would be better when building a system from scratch. A user of a pattern library should be aware of this. However the criterion does not reflect the core of a pattern as well as purpose and applies to.

  1. Criteria not chosen in my classification

Here I will discuss criteria from presented approaches to classification that I have excluded from my classification. These criteria are:

  1. Structural aspects

This criterion is used in the approach by Buschman et. al 12. They define structural principles as what patterns rely on to realize their functionality.

The four categories presented are (see page 23):

These are general design principles that guide design activities. A well-designed system should encompass these principles as much as possible. To me these aspects are principles that patterns also should follow but I do not believe that structural aspects makes a good criterion. The liabilities are:

Many patterns present solutions that meet more than one of these aspects. This is also true in Buschman et al's own interpretation of the criterion.

The categories are not very specific. It is hard to metric if a pattern should be allowed to join a category. For example to which extent must a pattern provide encapsulation to be placed in that category ?

These concepts are not as easy to comprehend as the criteria that I have chosen.

The criterion do not reflect the core of a pattern and as a consequence of the previous topics this criterion will not supply any help to a user of a pattern library in finding a specific pattern.

Note however that it is orthogonal to my criteria and could easily be added.

  1. Structural mechanisms

Structural criteria can be found in the approaches by Pree 9, Gamma 3 and Coad 4. Combining the approaches (see page 28, 22 and 27) brings these categories or groups of patterns:

These categories can not be used together as they intersect each other. I will not investigate interpretations of these groups further because I do not believe that structural mechanisms is a good criterion. The difficult part concerning structural mechanisms is that it is very hard to define categories. Pree 9 investigates patterns structurally from the aspects of hook and template methods and defines patterns at a higher level - metapatterns. The interested reader will find material there but I do not use this material. Structural aspects as a criterion has the following liabilities:

The criterion has low usability. I imagine a user seldom looks for a pattern that for example must be based on abstract coupling. A user looks for a solution and the key concern is not the structure of the solution. An analogy: Does a fisherman who is about to drown pay any attention to the fact that the water is made of oxygen and hydrogen ?

These demands can not be investigated as there are no categories defined. However in regard of the categories outlined above none of them is good. A pattern may use many structural methods such as inheritance, abstract coupling, objects, hook methods and template methods.


In this section I will outline concepts that are not used as classification criteria but provide additional functionality to a pattern library. First I propose an outlined solution on how to store and retrieve classification patterns. Then I propose how I believe that relationships (see page 25) could be of use in a pattern library.

  1. Abstraction

In a pattern library abstractionabstraction can be used as a search-tool for the classification patterns. The abstractions are the objects in the classification patterns that models a real-world counterpart. Each pattern described using Coad's 4 format contains a section called Examples (see page 19) which specifies what real-world entity the objects in the pattern models.

This choice not to develop a classification scheme for classification patterns mirrors the fact that classification patterns are at a more abstract level than design patterns and can be accessed by the concept that they are modelling. These modelled real-world objects can be kept in a dictionary. Compared to the classification scheme for the design patterns, a dictionary is more useful in finding patterns due to its high abstraction level. Here we do not need to talk in object-oriented terms such as objects and state but instead express ourselves in terms of real-world entities such as plans or transactions.

A classification pattern is a template to be used during classification. As the activity starts after requirements-analysis the user of a pattern library has a analysis-model containing real-world entities. A user of a classification library should be able to query the library if there are some classification patterns that models these entities.

  1. Relationships

Relationships can serve as a link between:

A relationship link from a classification pattern to a design pattern is a link that provides information on which design patterns that usually are used to overlay that classification pattern. For example, if a classification pattern outlines how to model a concept such as a picture it may contain links to the design patterns Proxy and Composite. Proxy can be used to save time and space when addressing the picture-object. Composite can be used to give the picture-object an interface that conforms with other drawing objects. Consequently these links may be named:

These links are not supported by Gamma et. al's format but they could easily be added.

A relationship link between two design patterns provides information on patterns that can be used together. These are the links that, as mentioned earlier, implicit will bring the concept of granularity into the library (see page 11). I will not investigate these relationships any further but use the work of Zimmer 13 (see page 25):

Finally note that a pattern library must have the ability to be updated. New links should be inserted whenever new relationships are found.


This section summons some thoughts about my work with the classification but also about design patterns in general. First I propose some hints on how to make a classification scheme for a library that includes patterns from a wider range of software development. I also propose hints on how to extend my classification scheme to support some sorts of domain dependent design patterns. Finally I will discuss the future of patterns and how I believe they will be used in developing software.

  1. Extending the classification scheme

As defined (see page 8) my classification scheme should be used to find patterns from a library that contains object-oriented design patterns. However, enlarging the library to support other kinds of software patterns would make the library more useful. This also imposes an enlargement of the classification scheme. One way to achieve this is to add criteria or categories to the existing classification scheme. Another way is to use multiple classification schemes. I will propose three hints on how to support other kinds of patterns. The first hint addresses supporting patterns from other software development phases by using multiple classification schemes. The other hints concern extending my scheme to support domain dependent and architectural patterns.

  1. Patterns from other development phases

The fact that the criterion activity forms the root in my classification scheme makes it possible to extend the classification scheme and include patterns that belong to other activities (phases) of software development such as analysis, process management and documentation. Such an extension is impossible without introducing additional criteria because patterns in these areas deal with subjects other than abstractions and objects. For example, patterns that address process management deals with subjects such as task-scheduling and economy. Consequently we will have to treat each phase differently. I believe there are two demands that patterns in such a general software library must meet:

Figure 9 shows possible extensions to activity:

Figure 9 Possible extensions of activity.

Such an extension would also introduce more links of relationships between patterns from different activities. This could result in a library that works as a pattern language and offers a user the possibility to follow links through the whole software process.

Techniques in using multiple classification schemes are available today. Approaches such as FOCS 22 make it possible to build libraries that support such schemes.

  1. Supporting domain dependent OO-design patterns

Another issue is extending my classification scheme for design patterns to support domain dependent patterns such as patterns from distributed programming. One suggestion is that the criterion applies to could be extended with the categories:

Which means that for example “Client-Server" would be a communication pattern that applies to remote families of objects.

Alternatively we could add criteria such as distributive and parallelism. These criteria would define the categories distributive, not distributive, parallel and not parallel.

This means that for example “Client-Server" would be a communication pattern that applies to families of objects and is distributive.

  1. Supporting architectural patterns

As mentioned earlier (see page 11) I use relationships to reflect granularity. Also I have made the interpretation that some of the architectural patterns can be viewed as object-oriented design patterns. However to extend the classification scheme to support all kinds of architectural patterns enlargements must be made.

The criterion applies to could be extended with the categories:

However even further enlargements must be made. For example the criterion purpose has categories that are too closely related to object-oriented entities to be of use in classifying architectural patterns because they do not impose a specific paradigm (see page 10).

  1. The future of patterns

I believe there is much work to be done before patterns become a useful tool in software developing. To become useful patterns must be a tool that supports the whole process of software developing. I believe that the role of object-oriented patterns is to be used as a complement to already existing object-oriented software development methods such as the Booch method 24, Coad/Yourdon 25, Object Modeling Technique 26 or Shlaer/Mellor 27. These methods define different processes for developing software. Within these processes object-oriented design patterns can be used to provide solutions to specific design problems.

As reusable entities patterns are more adaptable than classes because we are only reusing knowledge not code. Even if two applications uses the same class (abstraction) they may perceive it differently which reduces the degree of reuse. For example, an application that simulates football games can use the abstraction “man" and implement methods such as “shooting" and “passing". An application for aiding brain surgeons may also use the same abstraction but from another point of view.

Finally, I would like to stress that I believe that patterns are most useful as educational entities. Patterns as a form, especially object-oriented patterns, is very suitable for capturing good design techniques. Patterns provide working examples of good design made by experienced designers that are suitable for novices to learn. Keeping the patterns in a library is good but knowing the patterns by heart is better. The more people inspect patterns the faster the pattern-movement will evolve. New patterns will be discovered and old patterns will be refined. Some patterns will also become outdated as new technologies are developed. The classification scheme that I have presented is built on object-oriented features and will be valid only as long as object-oriented languages exist. Patterns however has the ability to outlive us all.



Christopher Alexander, Sara Ishikawa, and Murray Silverstein, with Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel.

A Pattern Language. New York: Oxford University Press, 1977.


Christopher Alexander. A Timeless Way of Building. New York: Oxford University Press, 1979.


Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison Wesley, 1995.


Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995.


J. Coplien, and D. Schmidt, eds. Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995.


Jim Coplien. Advanced C++: Programming Styles and Idioms

Reading, MA: Addison-Wesley, 1992.


J.M. Vlissides, J. Coplien, and N.L. Kerth, eds. Pattern Languages of Program Design 2. Reading, MA: Addison -Wesley, 1996.


Ralph E. Johnson. “Documenting frameworks using patterns" , WWW -Patterns Homepage, 1992


Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995.


Ted Lewis and friends. Object-Oriented Application Frameworks. Manning, 1995


James O. Coplien. “Software Design Patterns: Common Questions and Answers" , article, WWW - Patterns Homepage.


Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343.


Walter Zimmer. “Relationships Between Design Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 345-364.


Douglas C. Schmidt. “Reactor: An Object Behavioral Pattern for Concurrent Event Demultiplexing and Event Handler Dispatching." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 529-545.


Frank Buschman. “ The Master-Slave Pattern." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 133-142.


Mary Shaw. “Patterns for Software Architectures." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 453-462.


Bruce Whitenack. “RAPPeL: A Requirements-Analysis-Process Pattern Language for Object-Oriented Development." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 259-291.


Norman L Kerth. “Caterpillar's Fate: A Pattern Language for the Transformation from Analysis to Design." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 293-320.


Regine Meunier. “The Pipes and Filters Architecture." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 427-440.


Fred Halshall, Data Communications, Computer Networks and Open Systems. 3:ed. Addison-Wesley,1992.


James O. Coplien. “A Generative Development Process Pattern Language." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 183-237.


Jürgen Börstler, "Feature-Oriented Classification for Software Reuse". In Proceedings SEKE'95, The 7th International Conference on Software Engineering and Knowledge Engineering, Rockville, MD, USA, Jun (22-24) 1995, 204-211.


Frank Buschman “A system of patterns" , extract from the book A system of Patterns, John Wiley & Sons, 1996


Grady Booch, Object-Oriented Analysis and Design With Applications. Redwood City, California: Benjamin/Cummings, Second Edition, 1994.


P. Coad, E. Yourdon. Object-Oriented Analysis, Prentice Hall, Second Edition, 1991.


J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-Oriented Modeling and Design, Prentice Hall, 1991.


S. Shlaer, S.J. Mellor, Object-Oriented Systems Analysis - Modeling the World in Data, Yourdon Press, Prentice Hall, 1988.




Ensure that a class only has one instance, and provide a global point of access to it.


Creational, Object



Separate the building of a complex object from its representation so that the same construction process can create different representations.


Creational, Object


Intent: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

Classification: Creational, Object

Abstract Factory


Provide an interface for creating families of related objects without specifying their concrete classes.


Creational, Class

Factory Method


Define an interface for creating an object, but let subclasses decide which class to instantiate.


Creational, Class


Intent: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extended functionality.

Classification: Structural, Object



Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.


Structural, Object


Intent: Decouple an abstraction from its implementation so that the two can vary independently.

Classification: Structural, Object



Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.


Structural, Object


Intent: Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Classification: Structural, object

Chain of responsibility

Intent: 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.


Behavioural, object



Provide a surrogate or placeholder for another object to control access to it.


Structural, object


Intent: Without violating encapsulation, capture an externalize an object's internal state so that the object can be restored to this state later.

Classification: Behavioural, object


Intent: Encapsulate a request as an object thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

Classification: Behavioural, object


Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use it.

Classification: Behavioural, object


Intent: Allow an object to alter its behaviour when its internal state changes. The object will appear to change its class.

Classification: Behavioural, object


Intent: Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling between by keeping objects from referring to each other explicitely, and it lets you vary their interaction independently.

Classification: Behavioural, object


Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Classification: Behavioural, object


Intent: 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.

Classification: Behavioural, object



Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.


Behavioural, object

Template method


Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. TM lets subclasses redefine certain steps of an algorithm without changing the algorithms structure.


Behavioural, class



Given a language, define a representation for its grammar, along with an interpreter that uses the representation to interpret sentences in the language.


Behavioural, class


Intent: Use sharing to support large numbers of fine-grained objects efficiently.

Classification: Structural, object


To keep down the length of this appendix I will present a selected version of Coad's patterns. First I present a full version of the fundamental pattern then I give an overview over the pattern families. The interaction family is covered in greater detail.

The fundamental pattern (full)

#1 “Collection-Worker" Pattern the fundamental pattern

howManycalcForMe calcOverWorkerscalcForMe

howMuchcalcForMe rankWorkersrateMe

“aboutMe" help one think about what other attributes might be needed

“calcForMe" help one think about what specific calculations might be needed

“ rankMe" helps one think about what ordering or comparrison services might be

“rateMe" helps one think about what self-assessment services might be needed

Transaction patterns (overview)


Aggregate patterns (overview)


Interaction patterns (overview)

Contains: peer-peer, proxy-specific item, publisher-subscriber, sender- pass through receiver, sender-lookup-receiver, caller-dispatcher-caller back, gatekeeper-request-resource