See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220424606

The Pros and Cons of Adopting and Applying Design Patterns in the Real
World

Article  in  Communications of the ACM · October 1996

DOI: 10.1145/236156.236167 · Source: DBLP

CITATIONS READS

64 5,523

1 author:

Marshall Cline

14 PUBLICATIONS   303 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Marshall Cline on 16 June 2014.

The user has requested enhancement of the downloaded file.

 The Pros and Cons of Adopting and Applying
Design Patterns in the Real World
patterns are a valuable
D
ESIGN
tool for the practicing software
professional. There are a num-
ber of pragmatic benefits from
using design patterns, and, not
surprisingly, there are also a
number of common problems.
This sidebar shows project man-
agers and object-oriented (OO)
designers some of the organization-
al as well as technical issues that
come up when design patterns are
introduced into a software produc-
tion shop.
Practical Benefits:
Design patterns coordinate the entire
process and community. Design pat-
terns provide a standard vocabulary
among developers. They provide a
list of things to look for during a
design review and a list of things
that must be taught in a course on
OO design. They communicate
information between designer, pro-
grammer, and maintenance pro-
grammer at a significantly higher
level than individual classes or func-
tions.
These advantages of design pat-
terns scale well to large organiza-
tions. We have applied them on a
three-year project with 150
OO/C++ developers. Almost every
developer was trained and men-
tored using a uniform set of design
patterns, and these patterns were
used throughout the development
q,q,q.q,q,q.q,q,q.q,q,q.q,q,q.q,q,q.q,
M a r s h a l l P. C l i n e
lifecycle. Even though the patterns
and their names were different
from those in standard use today
(they were largely reinvented by the
author, since the project predated
the standard design patterns text
[3] by several years), they were
nonetheless uniform across the
project teams, and this uniformity
allowed the developers to commu-
nicate at a higher level of abstrac-
tion. Design patterns were an
important component to the over-
all success of this project [1].
Design patterns can be used reactively.
Design patterns can be used as a
documentation tool to classify the
fragments of a design, making it
easier for a team to absorb new
developers. For example, many of
the team’s design philosophies are
captured explicitly rather than
strictly being in the heads of the
original team.
Design patterns can be used proactively.
Patterns are more than a documen-
tation tool. In addition, they can be
used to build robust designs with
design-level parts that have well
understood trade-offs. Using
design patterns this way requires
the designer to perform a degree of
high-level pattern matching, as well
as to have the ability to abstract the
essence of the design problem from
the morass of details. It also
COMMUNICATIONS OF THE ACM
requires that the design patterns be
part of one’s flesh and blood—
looking things up in a book would
be completely unacceptable in
these on-the-fly situations.
Design patterns can be used to give the
software a hinge. One of the great
lies about OO is that it can be used
to build arbitrarily adaptable soft-
ware. In reality, adaptability must
be explicitly designed into the soft-
ware in designated places. OO soft-
ware is more like a human body
than a piece of silly putty: rather
than being arbitrarily adaptable
along every possible direction, it
has hinges or hot spots [4] in those
specific, designated places where
the software is designed to
bend/adapt. Future changes con-
sistent with one of these hinges are
relatively inexpensive, but forcing
the software to change in other
ways is like bending your elbow
backwards; the system normally
breaks.
For example, if a customer wants
to add new kinds of Foibles and/or
customize the way Foibles are dis-
played, it may be possible to build a
business case that justifies the
added expense of reducing the cost
to add Foibles and/or change their
display. These are two hinges; they
are places where the software is
designed to bend over time. Each
of these hinges will probably be
October 1996/Vol. 39, No. 10 47
 built using one or more design
patterns [2].
Unfortunately, the software
community is not very good at
dealing with hinges. Methodolo-
gies focus almost exclusively on
functional requirements, whereas
hinges are nonfunctional require-
ments. Very few methodologies
explicitly take hinges into account
during requirements analysis (e.g.,
use cases are functional, yet hinges
.q,q, are also requirements), when esti-
mating cost of the system (func-
tion points are functional, yet
q.q,q
The bottom line is
hinges are also expensive), during
testing (testing checks what the
software currently does rather
,q.q, than how easy it is to change the
software to do something else;
that every OO
q,q.q hinges/adaptability should be
explicitly tested), financial reward
system (most first-line managers
,q,q.
designer should learn
have a nine-month event horizon;
their job is to build it; they are not
rewarded if version two is cheap,
q,q,q
how to apply design
nor are they penalized if version
two is expensive).
.q,q,
Despite our failure as an indus-
try to adequately manage hinges,
they are extraordinarily impor-
q.q,q patterns.
tant, especially in today’s rapidly
changing business environment.
If a software system is not adapt-
,q.q, able, a company could miss a nar-
row market window. Some recent
billion dollar losses have been
traced to inflexible software sys-
tems.
Design patterns are one of the
first ways to explicitly manage
hinges. Some of the most useful
patterns are those that provide
hinges. For example, the Abstract
Factory Pattern makes it easy to
add new kinds of derived classes (a
hinge), even though parts of the
system have to create objects of
these new derived classes.
Design patterns can turn a trade-off
into a win-win situation. Very often
a designer has to make a choice
between two high-priority quali-
ties. Some of the most useful
design patterns are those that let a
designer work around these trade-
q,q,q.q,q,q.q,q,q.q,q,q.q,q,q.q,q,q.q,
48 October 1996/Vol. 39, No. 10 COMMUNICATIONS OF THE ACM
offs. Rather than forcing them to
choose between what would typi-
cally be mutually exclusive quali-
ties, these design patterns let the
designer give the software both
qualities simultaneously. For
example, one normally has to
choose between generality and
performance, but several patterns
allow arbitrary generality you pay
for only if you use (e.g., the Com-
posite Pattern provides this quality
with recursive structures).
Design patterns constrain mainte-
nance programmers. Hinges are rel-
atively expensive to design and
build, and some hinges can have
extraordinarily high business
value. Yet despite their cost and
their value, a hinge can be
destroyed by a careless change
that fixes a defect. Note that the
concern here is not that a change
may break another functional
requirement. The concern is that
a change may remove the soft-
ware’s ability to bend in ways that
it was previously able to bend.
Since few testing methodologies
explicitly test the hinges, mainte-
nance programmers are rarely
aware of the damage they have
wrought.
Design patterns help this prob-
lem. The likelihood that a mainte-
nance change will destroy
adaptability is significantly
reduced when designers explicitly
document the design patterns
used to build a hinge, particularly
when management puts processes
in place that require maintenance
programmers to understand and
preserve the integrity of these
design patterns during mainte-
nance changes.
Design patterns let management
reward self-directed designers: For bet-
ter or worse, today’s business cli-
mate often makes it necessary for
developers to expend unpaid over-
time to keep their skills sharp.
Thus, differentiating self-directed
developers from the others is an
important management problem.
 Even though this differentiation is
a nontechnical problem, design
patterns can help.
In practice, an OO designer
needs personal time and personal
initiative to become skillful in
design patterns. For instance, a
design pattern usually needs to be
used in a toy example before it can
be used under fire. Unfortunately,
some software professionals are
not self directed and are only will-
ing to put in the necessary time if
they are paid for it.
The bottom line is that every
OO designer should learn how to
apply design patterns. Designers
who are unable or unwilling to
learn the basic OO design patterns
[3] simply should not be doing
OO design. Those who are willing
to put in the personal time needed
to truly understand design pat-
terns should be rewarded with
continued employment and possi-
bly with increased responsibilities.
Inhibitors to Patterns
Applications
Design patterns have been oversold.
Design patterns are overly hyped.
They cannot possibly deliver the
benefits that some have naively
stated. Almost everyone in the
design patterns community has
been concerned about this for
some time, but unfortunately,
some consultants either do not
understand the limits of the tech-
nology or worse.
Design patterns have their
place, and they are very important,
especially when adaptability is a
valuable nonfunctional objective.
But adaptability is still not free,
and the benefits of using design
patterns will be wasted unless the
overall software development
process is modified to take design
patterns into account. For exam-
ple, every code review should
make sure the code accurately
reflects the constraints of the
appropriate design patterns, every
maintenance change should be
evaluated to make sure it doesn’t
break the constraints of the design
,q,q.q,q,q.q,q,q.q,q,q.q,q,q.q,.q,q.q,
View publication stats
patterns, and the adaptability of
the system’s design patterns
should be explicitly tested.
Some design patterns are unnecessarily
difficult to learn. Some design pat-
terns are simply too difficult for
the average OO designer to learn.
In some cases, the pattern is inher-
ently deep. Unfortunately, in
other cases the pattern is not
deep, but it is given a name
and/or description that isn’t obvi-
ous. This is probably the inevitable
result of the increase in the num-
ber of people proposing new
design patterns, and the frequency
of those proposals. Whatever the
cause, it is a practical problem
when patterns are adopted by an
organization, since murky, obfus-
cated design patterns tend to dis-
tract people from the clarity of
many writers and the depth of
their design patterns.
In our experience of training
and mentoring thousands of soft-
ware professionals in OO design
patterns, we found it helpful to
start with a vastly simplified state-
ment of a pattern’s purpose. After
the developers understand this
sound bite, they can graduate to
the fully general discussions and
descriptions that usually accompa-
ny a design pattern when it is pub-
lished.
Design pattern classifications are not
yet useful for practitioners. Design
patterns are classified along vari-
ous axes, such as purpose, scope,
and jurisdiction. These classifica-
tions are helpful to people who
already understand design pat-
terns, especially when determin-
ing whether a newly proposed
pattern is redundant with another
pattern that already exists. The
classifications have also helped
organize the huge number of pat-
terns, as there are now so many
patterns it is very difficult to
remember them all.
However, some of the cate-
gories are not helpful to software
practitioners while they learn pat-
COMMUNICATIONS OF THE ACM
terns. For example, some of the
criteria used to categorize design
patterns do not appear to map to
mental models used by the aver-
age developer. This is a fruitful
research opportunity that crosses
discipline boundaries between
computer science and psychology.
For example, psychological stud-
ies should be conducted to see
how typical software designers cat-
egorize patterns in their own
minds, and the formal categoriza-
tion of design patterns should be
redone to reflect these natural cat-
egories.
Conclusion
The software project manager and
OO designer can expect to benefit
from applying design patterns. To
maximize this benefit, design pat-
terns should be applied uniformly
throughout the organization, and
expectations should be managed
carefully.
Like any new discipline, it takes
time for the design pattern
approach to mature. However, if
the software development organi-
zation is willing to adapt its
processes to weave design patterns
throughout the software lifecycle
and to invest in appropriate train-
ing and mentoring, there are prac-
tical benefits available now. C
References
1. Berg, B., Cline, M. and Girou, M.
Lessons learned from the OS/400 OO
project. Commun. ACM 38, 10 (1995).
2. Cline, M. and Fayad, M. Object-Oriented
Design Patterns (1995) Course notes,
800 pages.
3. Gamma, E. et al. Design Patterns. Addi-
son-Wesley, Reading, Mass., 1995.
4. Pree, W. Design Patterns for Object-Orient-
ed Software Development. Addison-Wesley,
Reading, Mass., 1995.
5. Schmidt, D. Using design patterns to
develop reusable object-oriented com-
munication software. Commun. ACM 38,
10 (1995).
Marshall P. Cline is president of Paradigm
Shift, Inc., Potsdam, N.Y., cline@parashift.
com.
©ACM 0002-0782/96/1000
October 1996/Vol. 39, No. 10 49