Figure
1: Class diagram of Composite.
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 103.3.1.1 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.
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.
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:
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"."
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.
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:
Intent
Composite objects into tree structures to represent
part-whole hierarchies. Composite lets clients treat individual
objects and compositions of objects uniformly.
Motivation
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.
Applicability
Use the composite pattern when
Structure
Participants
Collaborations
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.
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:
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".
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:
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.
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.
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.
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.
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:
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.
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.
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.
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:
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
| Classification Patterns | Design Patterns |
| Transaction patterns (Coad) | All patterns from Gamma et. al |
| Plan patterns (Coad) | Interaction patterns (Coad) |
| Aggregate patterns: (Coad) |
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).
The criterion activity is not found in any
of the covered approaches to classification.
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.
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.
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.
| Object | Obj-families | Related Obj-families |
| Builder | Facade | Abstract Factory |
| Factory Method | Mediator | Composite |
| Prototype | Observer | Bridge |
| Singleton | Visitor | Flyweight |
| Adapter | Command | Chain of responsibility |
| Decorator | Template Method | |
| Proxy | ||
| Iterator | ||
| Memento | ||
| Strategy | ||
| State |
A similar criterion is not used in any of the covered
approaches to classification.
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.
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.
| Instantiation | Interface | Functionality |
| Abstract Factory | Facade | Decorator |
| Factory Method | Composite | Visitor |
| Builder | Adapter | Strategy |
| Prototype | Bridge | Template Method |
| ACCESS | STATE | COMMUNICATION |
| Proxy | Memento | Chain of Responsibility |
| Iterator | State | Mediator |
| Observer | ||
| Command |
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.
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.
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.
| Static | Dynamic |
| Factory Method | All other patterns |
| Adapter (class) | |
| Template Method | |
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.
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.
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.
| Reusing | Building |
| Adapter | All other patterns |
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.
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.
Here I will discuss criteria from presented approaches to classification that I have excluded from my classification. These criteria are:
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.
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.
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.
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.
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.
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.
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.
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).
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.
1
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.
2
Christopher Alexander. A Timeless Way of Building. New York: Oxford University Press, 1979.
3
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison Wesley, 1995.
4
Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995.
5
J. Coplien, and D. Schmidt, eds. Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995.
6
Jim Coplien. Advanced C++: Programming Styles and Idioms
Reading, MA: Addison-Wesley, 1992.
7
J.M. Vlissides, J. Coplien, and N.L. Kerth, eds. Pattern Languages of Program Design 2. Reading, MA: Addison -Wesley, 1996.
8
Ralph E. Johnson. “Documenting frameworks using patterns" , WWW -Patterns Homepage, 1992
9
Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995.
10
Ted Lewis and friends. Object-Oriented Application Frameworks. Manning, 1995
11
James O. Coplien. “Software Design Patterns: Common Questions and Answers" , article, WWW - Patterns Homepage.
12
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.
13
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.
14
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.
15
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.
16
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.
17
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.
18
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.
19
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.
20
Fred Halshall, Data Communications, Computer Networks and Open Systems. 3:ed. Addison-Wesley,1992.
21
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.
22
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.
23
Frank Buschman “A system of patterns" , extract from the book A system of Patterns, John Wiley & Sons, 1996
24
Grady Booch, Object-Oriented Analysis and Design With Applications. Redwood City, California: Benjamin/Cummings, Second Edition, 1994.
25
P. Coad, E. Yourdon. Object-Oriented Analysis, Prentice Hall, Second Edition, 1991.
26
J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-Oriented Modeling and Design, Prentice Hall, 1991.
27
S. Shlaer, S.J. Mellor, Object-Oriented Systems Analysis - Modeling the World in Data, Yourdon Press, Prentice Hall, 1988.
Singleton
Intent:
Ensure that a class only has one instance, and provide a global point of access to it.
Classification:
Creational, Object
Builder
Intent:
Separate the building of a complex object from its representation so that the same construction process can create different representations.
Classification:
Creational, Object
Prototype
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
Intent:
Provide an interface for creating families of related objects without specifying their concrete classes.
Classification:
Creational, Class
Factory Method
Intent:
Define an interface for creating an object, but let subclasses decide which class to instantiate.
Classification:
Creational, Class
Decorator
Intent: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extended functionality.
Classification: Structural,
Object
Adapter(object)
Intent:
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
Classification:
Structural, Object
Bridge
Intent: Decouple an abstraction from its implementation so that the two can vary independently.
Classification: Structural,
Object
Facade
Intent:
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.
Classification:
Structural, Object
Composite
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.
Classification:
Behavioural, object
Proxy
Intent:
Provide a surrogate or placeholder for another object to control access to it.
Classification:
Structural, object
Memento
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
Command
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
Strategy
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
State
Intent: Allow an object to alter its behaviour when its internal state changes. The object will appear to change its class.
Classification: Behavioural,
object
Mediator
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
Observer
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
Visitor
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
Iterator
Intent:
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
Classification:
Behavioural, object
Template method
Intent:
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.
Classification:
Behavioural, class
Interpreter
Intent:
Given a language, define a representation for its grammar, along with an interpreter that uses the representation to interpret sentences in the language.
Classification:
Behavioural, class
Flyweight
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)
Contains:
Aggregate patterns
(overview)
Contains:
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
