Hey there! Welcome to second part of a series of articles on design patterns.
In case you tuned in late, the previous article looked at what design patterns could/could not do & some reasons why we need to use them. In this article, we look at the evolution of design patterns, categorizing the design patterns & their definitions, and a list of all the different patterns out there.
Once upon a time...
Once upon a time in a land far away there lived an achitect (who designs & builds buildings for a living, duh!) by name Christopher Alexander who produced a pattern language as: an architectural concept to empower any human being to design & build at any scale.
Kent Beck & Ward Cunningham began experimenting with these ideas to apply them to software. They presented using pattern languages for object-oriented programs at the OOPSLA & the rest was history.
Design patterns were here to stay with important contrbutions from THE Gang of Four & THE Martin Fowler to name a few experts in this area of work.
Moral of the story:
Its cool to be an "architect" in a software company, with having nothing to do designing & building buildings!
The Classic Categorization of design patterns
| Creational |
These set of patterns deal with special mechanisms to handle the creation of objects
|
| Abstract Factory |
used to create an instance of several families of classes
|
| Factory |
used to create an instance of several derived classes
|
Builder
|
seperates object construction from its representation |
| Lazy initialization |
delays the creation of the object till the first time it is needed
|
Object Pool
|
maintains & releases a pool of resources by recycling objects
|
Prototype
|
used when the type of object to create is determined by the prototypical instance, which is cloned to produce new objects
|
Singleton
|
restricts to hanving only one instance of the class |
| Structural |
These set of patterns identify a simple way to realize the relationship between entities |
| Adapter |
provides a mechanism to match the interfaces of two classes
|
Bridge
|
seperates an abstraction (Interface) from its implementation (class) so that both can vary independantly |
Composite
|
compose objects into tree structures to represent part-whole heirarchies
|
Decorator
|
used to add new/additional functionality to an existing class dynamically
|
Facade
|
used to provide a single interface to a larger set of interfaces by hiding that large set
|
Flyweight
|
is an object that minimizes memory occupation by sharing as much data as possible with other similar objects
|
Proxy
|
is an object which represent another object that is expensive to duplicate
|
| Behavioral |
These set of patterns identify common communication patterns between objects |
| Chain of responsibility |
a way of passing a request between a chain of objects
|
Command
|
encapsulate a command request as an object |
Interpreter
|
a way to include language elements in a program |
Iterator
|
sequentially access the elements of a collection |
| Mediator
|
defines simplified communication between classes |
Memento
|
capture and restore an object's internal state |
Observer
|
a way of notifying change to a number of classes |
State
|
alter an object's behavior when its state changes |
Strategy
|
encapsulates an algorithm inside a class |
| Template |
defer the exact steps of an algorithm to a subclass |
Visitor
|
defines a new operation to a class without change |
Source: dofactory.com
Domain-specific patterns
Besides the classic categories of design patterns as shown above, there is a very huge list of patterns, some of which are domain-specific. Some examples of such patterns are UI design patterns, concurrency patterns, AJAX patterns, Web development pattern etc. which focus on solving software design issues for that domain.
Not a silver bullet
There have been numerous crticisms of design patterns here and here and an interesting defense too! As pointed out in the previous article, design pattern is no silver bullet. It is just a framework to get our mind around to understanding a problem.
So, if this framework helps in solving a design problem, that is cool; if not, that is cool too - is my take on this subject.
Lotsa text, wassup next?
We are done with understanding some history of design patterns, their categorization & some definitions of what each pattern means.
The next article promises to be more fun as we will start looking at the actual implementation of the patterns in terms of code, identify a few real-life examples where we can use it & hopefully get to hear your experiences & gotcha's with the pattern.
So stay tuned, code coming up!