Comfortable Introduction to Design Patterns

Design Pattern

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 which
you should copy.

We 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:

A design pattern is simply a description of a recurring
solution to a problem, given a context.

Design patterns are language-independent strategies for solving common object-oriented design problems. Hence they should be equally applicable no matter which object-oriented language you use. Design patterns are not idioms or algorithms or components.

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:

Name of the pattern:
One should definitely know the design pattern he is going to be using to avoid miscommunication with others

Scenario when to use the pattern:

As I said there are so many patterns and it is easy to misuse them. A clear understanding of the problem scenario and when to use them is critical to gaining the maximum benefit of using a particular pattern. Often there are many variations/multiple ways to implement a particular pattern. A good understanding of the problem scenario helps one take the correct decision
while facing these choices.

Consequence of using the pattern:

One should also realize the advantages and disadvantages of using a particular pattern. Often a clear understanding of these help eliminate choices when we are faced with choices amongst multiple design patterns for a particular problem.

Design patterns can be classified in two ways mainly:

1) What the Pattern does

Creational Patterns:
They deal with various mechanisms of object creation. Examples include Abstract Factory, Factory Method, Singleton, Prototype and Builder patterns.

Structural Patterns:
They deal with the structure i.e. composition of classes and objects. Common examples include Adapter, Composite, Bridge, Decorator, and Proxy patterns.

Behavioral Patterns:

They deal with means of communication between objects. Common examples include Strategy, Observer, and Visitor patterns.

2) What kind of relationships it focuses on

Class Patterns:
They deal with inheritance, i.e. the ‘is a’ relationship of classes. Examples include Factory Method pattern.

Object Patterns:

They deal with relationships between objects, i.e. the ‘has a’ relationship of objects. Examples include the Abstract Factory

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.

--