Over the last few days we have been having design pattern sessions for everyone at our firm. So I thought it would be an opportune time to let everyone know about my understanding of design patterns. Over the course of time I also intend to write about a couple of design patterns.
So what actually is a pattern and what actually is a design pattern. The dictionary definition of a ‘pattern’ is as follows:
Pattern (noun): model/example whichWe apply patterns in many facets of our life. It is only but obvious then that we should apply patterns even in software development. We may apply patterns while designing a solution to a particular problem we have. These patterns are what we call Design Patterns in software development. More formally a design pattern can be defined as follows:
you should copy.
Before beginning to read more on the various design patterns I think we should realize that these patterns as such are not really invented by anyone in particular. They have just evolved over time by different people (software engineers) who faced various problem and come up with solutions to them. In fact it is possible that we have been using many design patterns without knowing their names. For example I had been using singletons, strategy and facades even before we had started the sessions in my firm.
Though I was applying some design patterns without knowing them I actually found benefits from a formal study of them. For one having these discussions helped me better understand what these design patterns actually are and how best to apply them. It has also helped improve out vocabulary and communication between team members. In fact we even use the
names of many of the design patterns in our everyday vocabulary in the office, for e.g. delegating responsibilities and giving proxies. Most importantly, a design pattern facilitates change requests from your client, a given during the life cycle of any software.
At first reading through design patterns and actually applying those in our designs and solutions might seem like a lot of hassle. But in the long run they really pay off. In fact one of the goals of design patterns is to make our software design reusable. Using the right design pattern in our solution results in the final product being more flexible and the inner components being reusable. Notice that I used the word ‘right’ because there are so many design patterns and it is easy to misapply them.
Hence while reading on a design pattern one should be careful to note the following:
One should definitely know the design pattern he is going to be using to avoid miscommunication with others
Scenario when to use the pattern:
while facing these choices.
Consequence of using the pattern:
Design patterns can be classified in two ways mainly:
1) What the Pattern does
They deal with various mechanisms of object creation. Examples include Abstract Factory, Factory Method, Singleton, Prototype and Builder patterns.
They deal with the structure i.e. composition of classes and objects. Common examples include Adapter, Composite, Bridge, Decorator, and Proxy patterns.
They deal with inheritance, i.e. the ‘is a’ relationship of classes. Examples include Factory Method pattern.
Just another point before ending today is that one needs to read as many design patterns as possible. It is because design patterns are rarely used in isolation. More commonly they are always used in conjunction with other design patterns.
Check back again soon. I hope to write on the Abstract Factory and Factory Method patterns soon.