Thinking in C++ Vol 2 - Practical Programming
Prev	Home	Next

Features, idioms, patterns

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.[135] 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