Design Patterns | An Overview
The origins of Design Patterns
Back in the 90s, object-oriented programming was the talk of the town. The programmers were bejewelling their codebase with superclasses, virtual functions, and complicated inheritance. Not coincidentally, the programmers often ran into trouble given the limitations of then programming languages.
It was the “Gang of Four” who first introduced the idea of Design Patterns. The GoF were inspired by the concept of architectural patterns (yes, namespace: civil) that defined a language for town planning. The window dimensions, levels in a building, parks in the neighborhood, etc. were the important aspects of town planning.
The book “Design Patterns: Elements of Reusable Object-Oriented Software” or simply the “GoF book”, featured 23 patterns that attempted to solve commonly occurring object-oriented design. These designs are not bound to any specific programming language.
What are Design Patterns?
- Design patterns are not a set of code snippets or libraries that one can readily use in their codebase.
- Design Patterns are merely the blueprints that solve a recurring design problem.
- They can be liberally customized to fit a specific implementation.
- They are not bound to any specific language, but it can get very challenging to implement (a few) design patterns given the limitations of certain languages.
Classification of patterns
Idioms are low-level implementations that dictate the use of language-specific features to form the components building higher-level architectural patterns. Architectural patterns are the abstraction of design patterns at a higher level.
“Idioms are language-specific.”
“Architectural patterns are applied over an entire application or the system.”
Again, “Design patterns intended to solve design problems... on a modular level.”
Classification of Design Patterns
Depending on the purpose or the problem that patterns are addressing, these are the following classifications:
- Creational patterns deal with object creation mechanisms, trying to increase efficiency, code reuse, and flexibility. (checkout my detailed post)
- Structural patterns deal with the composition of objects and classes into larger structures while making them flexible and efficient. (read more)
- Behavioral patterns deal with the complex control flow and the assignment of responsibilities between objects. (read more)
When are Design Patterns not preferred?
Patterns do not magically improve the quality of a codebase. Adding patterns that fail to address the right problems will certainly cause code maintenance hell.
Novice developers who have just familiarized themselves with patterns need not start out trying to use patterns. Most often simpler code would do just fine. But, for someone who hasn’t explored patterns yet, it is definitely worth investing good amount of time.