Object-orientated designs

In software development, a design pattern describes a relatively small, well-defined aspect of a computer program in terms of how code is to be written. The purpose of using a pattern is to utilise an existing concept rather than reinventing it. This can reduce the time required for software development and increase the quality of the resulting programme.

Conformity to patterns is not a measure of quality. [1]

Although design patterns are language-independent, this does not mean that every pattern is suitable for every language. In his talk Design Patterns in Dynamic Languages from 1996, Peter Norvig states that 16 of the 23 patterns from the classic book Design Patterns become either invisible or simpler in a dynamic language [2]. The authors of the book also recognise in their introduction that the implementation language determines which patterns are relevant:

The choice of programming language is important because it influences the perspective. Our patterns are based on Smalltalk/C++ language features, and this choice determines what can and cannot be easily implemented. If we had started from procedural languages, we might have included design patterns labelled inheritance, encapsulation and polymorphism. Similarly, some of our patterns are directly supported by the less common object-oriented languages.

Norvig suggests, among other things, replacing the strategy pattern with instances of some classes with simple functions and thus reducing a lot of boilerplate code. In the following strategy pattern section, we will refactor the strategy pattern using function objects.

SOLID is an acronym for five design principles that are intended to make object-orientated designs more comprehensible, flexible and maintainable.

See also