Design Patterns21 Jul 2013
In software engineering, design patterns are software development patterns that make code re-usable and less bug-prone. These are tried and tested patterns that fit in particular scenarios.
This post is evolving and will have series linked to this original post. Keep watching this space for updates
Design patterns are the template to tell us how to solve a problem in similar scenarios
The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. — Christopher Alexander (from Wikipedia)
Design patterns help us speed up the development by providing tested, proven development paradigms. Software design requires foreseeing issues that may not become visible until later in the project phase.
Using design patterns helps to prevent issues that can cause major problems. Design problem also helps in making code readable and more predictable for developers as most of them would be familiar with existing patterns than ad-hoc designs.
Additionally, design patterns allow developers to communicate using well-known, well-understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.
Design patterns can be broken into three categories broadly. In this section, we would be categorizing popular design patterns and we may discuss them in detail in subsequent sections.
Creational Design Patterns
As the name suggests, these design patterns are one associated with the initialization of class, object, or modules. The implementation of these patterns depends on the type of programming language and grammar used therein. Here are few design patterns falling into this category
- Singleton — A class of which only one object can be created and exist
- Object Pool — A finite number of objects are created at project initialization and re-used for lifecycle, instead of expensive allocating and de-allocating resources
- Prototype — An instance to be copied over or cloned as and when needed
- Builder — To separate object presentation from its creation
- Factory — Help to create an instance of several similar derived classes through a common interface
Structural Design Patterns
These design patterns tell us how to compose Classes and Objects to create complex entities. These also help us in identifying relationships among entities and obtain new functionality. These design patterns encourage a developer to design smaller entity based on single responsibility principal
- Adaptor — Make different interfaces act similar (i.e drivers, db adaptors)
- Composite — To compose smaller entity to create a complex one
- Decorator/Presenter — Adding responsibility to entities dynamically
- Proxy — An entity faking other entity
- Bridge — Separates entity’s interface from its implementation
- Facade — Single entity representing or making complex club of entities
Behavioral Design Patterns
In software engineering, behavioral design patterns are design patterns that identify common communication patterns among objects and realize these patterns. This enhances flexibility in carrying out communication
- Chain of Responsibility — Consisting of a command object and series of processing objects
- Interpreter — Consist of an interpreter defining grammatical representation for a language
- Iterator — Sequentially iterate collection of entities
- Mediator — Communicator entity between entities
- Observer — Notifies changes in an entity to associated entities
- Template — Defer exact steps of an algorithm to a sub-entity
- Command — Encapsulate a command request as an entity
- Visitor — Adding a new operation to entity without modifying it
- Strategy — enables selecting an algorithm at runtime as needed
- State — Allows entity to change behavior as per its state
- Null Object — Acts as a default value to an entity
- Memento — Captures the entity’s internal state and restore on demand
Design Patterns while being popular in the field of Computer Science, but at the same time, it has been criticized by some. Here are some popular criticisms:
Design Patterns are Lazy Design
Contemporary programmers often copy-paste code without considering its implications, sometimes specific to a particular programming paradigm. These are not suitable for other programming paradigms. Most problems are unique and complex while design patterns are simple and re-usable. [Rething Design Patterns]
One size does not fit all
Some design pattern targets shortcoming of a programming paradigm and is specific to those programming paradigms. Design Pattern tries to fit them to other paradigm and that can disastrous. (e.g iterator pattern is different for functional and OOP paradigms)
Peter Norvig provides a similar argument. He demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan. Peter Norvig also points out that over half of the design patterns in the 1994 book are workarounds for missing language features.
Common Designs may be Bad Designs
Just because something is commonly used doesn’t make it a good idea. It could be bad, or even disastrous. Singletons, for example, are sometimes seen as trying to avoid object-orient design [Design Patterns: Magic or Myth?]
Design Patterns Increase Complexity
Using inappropriate patterns can be like trying to force a square peg into a round hole: adding additional work and unnecessary dependencies. Some of the modern dynamic languages do not even implement classes or do not fall under OOPs paradigm [Design Patterns Suck].
Please follow to keep watching for new posts. Thanks for reading