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
