Thinking in C++ Vol 2 - Practical Programming |
Prev |
Home |
Next |
Work continues beyond what is in the GoF book. Since its
publication, there are more patterns and a more refined process for defining
design patterns. This
is important because it is not easy to identify new patterns or to properly
describe them. There is some confusion in the popular literature on what a
design pattern is, for example. Patterns are not trivial, nor are they
typically represented by features that are built into a programming language. Constructors and destructors, for example, could be called the guaranteed
initialization and cleanup design pattern. These are important and essential
constructs, but they re routine language features and are not rich enough to be
considered design patterns.
Another non-example comes from various forms of aggregation. Aggregation is a completely fundamental principle in object-oriented
programming: you make objects out of other objects. Yet sometimes this idea is
erroneously classified as a pattern. This is unfortunate because it pollutes
the idea of the design pattern and suggests that anything that surprises you
the first time you see it should be made into a design pattern.
The Java language provides another misguided example: The
designers of the JavaBeans specification decided to refer to the simple
get/set naming convention as a design pattern (for example, getInfo( )
returns an Info property and setInfo( ) changes it). This is
just a commonplace naming convention and in no way constitutes a design
pattern.
Thinking in C++ Vol 2 - Practical Programming |
Prev |
Home |
Next |