| Thinking in C++ Vol 2 - Practical Programming |
|
Prev |
Home |
Next |
Initially, you can think of a pattern as an especially
clever and insightful way to solve a particular class of problem. It appears
that a team of people have worked out all the angles of a problem and have come
up with the most general, flexible solution for that type of problem. This
problem could be one that you have seen and solved before, but your solution
probably didn t have the kind of completeness you ll see embodied in a pattern.
Furthermore, the pattern exists independently of any particular implementation
and it can be implemented in a number of ways.
Although they re called design patterns, they really
aren t tied to the realm of design. A pattern seems to stand apart from the
traditional way of thinking about analysis, design, and implementation.
Instead, a pattern embodies a complete idea within a program, and thus it might
also span the analysis phase and high-level design phase. However, because a
pattern often has a direct implementation in code, it might not show up until
low-level design or implementation (and you might not realize that you need a
particular pattern until you get to those phases).
The basic concept of a pattern can also be seen as the basic
concept of program design in general: adding layers of abstraction. Whenever you abstract something, you re isolating particular details, and one of the most
compelling motivations for this is to separate things that change from
things that stay the same. Another way to put this is that once you find
some part of your program that s likely to change, you ll want to keep those
changes from propagating side effects throughout your code. If you achieve
this, your code will not only be easier to read and understand, but also easier
to maintain which invariably results in lowered costs over time.
The most difficult part of developing an elegant and
maintainable design is often discovering what we call the vector of change. (Here, vector refers to the maximum gradient as understood in the sciences,
and not a container class.) This means finding the most important thing that
changes in your system or, put another way, discovering where your greatest
cost is. Once you discover the vector of change, you have the focal point
around which to structure your design.
So the goal of design patterns is to encapsulate change.
If you look at it this way, you ve been seeing some design patterns already in
this book. For example, inheritance could be thought of as a design pattern
(albeit one implemented by the compiler). It expresses differences in behavior
(that s the thing that changes) in objects that all have the same interface
(that s what stays the same). Composition could also be considered a pattern,
since you can change dynamically or statically the objects that implement your
class, and thus the way that class works. Normally, however, features that are
directly supported by a programming language have not been classified as design
patterns.
You ve also already seen another pattern that appears in
GoF: the iterator. This is the fundamental tool used in the design of
the STL, described earlier in this book. The iterator hides the particular
implementation of the container as you re stepping through and selecting the
elements one by one. Iterators allow you to write generic code that performs an
operation on all the elements in a range without regard to the container that
holds the range. Thus, your generic code can be used with any container that
can produce iterators.
| Thinking in C++ Vol 2 - Practical Programming |
|
Prev |
Home |
Next |
