Object Oriented Programming: Evaluation of design patterns

Sun, Jun 11, 2017 ❝The evaluation of a number of design patterns against notions defined in earlier blog posts.❞

Contents

This article was started more than a year ago and was intended to be a close follow up in the series. I never did find the time to release it in that time frame, so now I decided to finish it more than a year later.

Given the definitions of usage logic and implementation logic and the distinction between internal state and expectations, we evaluate the well-known Gang of Four design patterns and some other design patterns. By determining type of logic and type of state, we can determine the nature of a pattern. Is a pattern set up as a utility or as a full-fledged object with its own concerns.

Of course, it is possible to make any object into a full-fledged object with all possible object-oriented constructs. Just as it is possible to apply any number of design patterns to any piece of code. Even code as simple as a single function can be “enhanced” by design patterns. We should focus on what is really needed, instead of what is maximally possible.

Utility:

Utility methods exist to do slight adaptations of the core object(s) for which it is a utility. Method calls to utility methods typically behave independently of each-other. Given that there is no internal state in which to keep a record of previous activities, we rely solely on data provided to us through parameters and initially set expectations.

Augmentation:

Not reliant on internal state for basic use. Not reliant on privileged access/implementation logic.

• Adapter
• Bridge
• Chain of responsibility
• Composite
• Decorator
• Facade
• Observer
• Proxy
• Strategy
• Visitor

Creation/Implementation:

Not reliant on internal state for basic use. Special-cases creation.

• Abstract factory
• Factory
• Template method

Object:

Objects contain logic and state. Objects behave intelligently and consequently have their own state to manage. Objects can keep record of operations over time and therefore are able to relate previous method calls to future method calls if necessary.

Reliant on internal state for basic use. Reliant on privileged access to internal state.

• Builder
• Command
• Factory method
• Flyweight
• Iterator
• Mediator
• Memento
• Prototype
• Singleton

Multiple objects:

Some patterns require multiple objects to demonstrate their application.

• State
• Interpreter

Conclusions

The post classifies design patterns by the extent of their use of/reliance on internal state. About half of the well-known design patterns are utilities in the simplest form. Some utilities rely on special cases of construction to provide their function. And the remaining half relies on full capabilities of the object in order to provide their function.

I am not sure what to conclude from this, other than to say that there is quite some powerful constructs that can be realized as “mere utilities”. With the right understanding of object orientation, all of these patterns seem trivial evolutions of the application of basic objects. This article is more of an exploration of the earlier ideas in practice and to see if it is possible to classify existing patterns according to the previously defined and described properties.