The
Design
Patterns
book discusses 23 different patterns, classified under three purposes (all of
which revolve around the particular aspect that can vary). The three purposes
are:
Creational:
how an object can be created. This often involves isolating the details of
object creation so your code isn’t dependent on what types of objects
there are and thus doesn’t have to be changed when you add a new type of
object. The aforementioned
Singleton
is classified as a creational pattern, and later in this chapter you’ll
see examples of
Factory
Method
and
Prototype.
Structural:
designing objects to satisfy particular project constraints. These work with
the way objects are connected with other objects to ensure that changes in the
system don’t require changes to those connections.
Behavioral:
objects that handle particular types of actions within a program. These
encapsulate processes that you want to perform, such as interpreting a
language, fulfilling a request, moving through a sequence (as in an iterator),
or implementing an algorithm. This chapter contains examples of the
Observer
and the
Visitor
patterns.
The
Design
Patterns
book has a section on each of its 23 patterns along with one or more examples
for each, typically in C++ but sometimes in Smalltalk. This book will not
repeat all the details of the patterns shown in
Design
Patterns
since that book stands on its own and should be studied separately. The catalog
and examples provided here are intended to rapidly give you a grasp of the
patterns, so you can get a decent feel for what patterns are about and why they
are so important.
[[
Describe different form of categorization, based on what you want to accomplish
rather than the way the patterns look. More categories, but should result in
easier-to-understand, faster selection ]]]
Features,
idioms, patterns
How
things have gotten confused; conflicting pattern descriptions, naïve
“patterns,” patterns are not trivial nor are they represented by
features that are built into the language, nor are they things that you do
almost all the time. Constructors and destructors, for example, could be called
the “guaranteed initialization and cleanup design pattern.” This is
an important and essential idea, but it’s built into the language.
Another
example comes from various forms of aggregation. Aggregation is a completely
fundamental principle in object-oriented programming: you make objects out of
other objects [[ make reference to basic tenets of OO ]]. Yet sometimes this
idea is classified as a pattern, which tends to confuse the issue. This is
unfortunate because it pollutes the idea of the design pattern and suggest that
anything that surprises you the first time you see it should be a design pattern.
Another
misguided example is found in the Java language; the designers of the
“JavaBeans” specification decided to refer to a simple naming
convention as a design pattern (you say
getInfo( )
for a member function that returns an
Info
property and
setInfo( )
for one that changes the internal
Info
property; the use of the “get” and “set” strings is
what they decided constituted calling it a design pattern).
Basic
complexity hiding
You’ll
often find that messy code can be cleaned up by putting it inside a class. This
is more than fastidiousness – if nothing else, it aids readability and
therefore maintainability, and it can often lead to reusability.