Design Patterns !!!!

Every Software Developer is very much familiar with this term “Design Patterns”. Any Graduate about to join a company is aware of design patterns, and he is taught that he should also understand design patterns and is supposed to use it extensively. All Experienced developers keeps on advising the juniors, “you need to understand design patterns”. Well, so every one is aware of this term and newbies are the most who gets frustrated by hearing this.
The other questions never asked by a newbie, but always been in their mind from day one is “What is Design Pattern?” and  “Why do i need them?”…

I am trying to address both here and throw some light into what is a design pattern and a small introduction about it.

What is Design Patterns?

History

Design patterns has its history to the roots of a civil engineer, Christopher Alexander, who published a book on his wisdom of experience gained on the recurring problems and solutions existed in Construction. Being in a construction field, he noticed that the problems existed with every new site construction and the nature was recurring, which forced him to assemble his experience in a book which was the first design pattern book ever in history. The book helped the new comers in solving the problems very easily rather than re-inventing the wheel over and again.

Software Professionals took the same idea and came up with the first ever publication of “Design Patterns: Elements of Reusable Object-Oriented Software” in 1995 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. (they are usually known as Gang Of Four). This book covered 23 patterns initially when they published it. All those patterns were based on the experience GOF were having during the times

Gang of Four (GOF)

Erich Gamma

Erich Gamma

Erich Gamma is a co-author of the influential computer science textbook, Design Patterns. He co-wrote the JUnit software testing framework with Kent Beck and led the design of the Eclipse platform’s Java Development Tools

Richard Helm is currently with The Boston Consulting Group where he consults on the strategic application of technology to business. His career spans high technology research, product development, systems integration, and IT consulting.

Ralph E. Johnson is a Research Associate Professor in the Department of Computer Science at the University of Illinois at Urbana-Champaign. He is an early pioneer of small talk community

John Matthew Vlissides was a software scientist and a pioneer in design patterns.

Overview

Design patterns are defined as time tested solutions for recurring design problems. When somebody has already solved your problems, then why to re-invent the wheel again. Exactly that’s what the design pattern is doing, it has already solved most of your problems.

One thing expert designers know NOT to do is to solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is part of what makes them experts. Consequently, you’ll find recurring patterns of classes and communicating objects in many object-oriented systems. That’s what GOF has done in their book of design pattern. I hope, now we have a good idea about what a design pattern is all about and why its needed.

Different Patterns

Here we will have an overview of the 23 patterns first defined by GOF.

Patterns are categorized into three kinds:

Creational Patterns

As the name suggests, Creational design patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented.

  • Abstract Factory – groups object factories that have a common theme.
  • Builder – constructs complex objects by separating construction and representation.
  • Factory Method – creates objects without specifying the exact class to create.
  • Prototype – creates objects by cloning an existing object.
  • Singleton – restricts object creation for a class to only one instance.

Structural Patterns

Structural patterns are concerned with how classes and objects are composed to form larger structures.
Structural class patterns use inheritance to compose interfaces or implementations.

  • Adapter – allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
  • Bridge – decouples an abstraction from its implementation so that the two can vary independently.
  • Composite – composes one-or-more similar objects so that they can be manipulated as one object.
  • Decorator – dynamically adds/overrides behaviour in an existing method of an object.
  • Facade – provides a simplified interface to a large body of code.
  • Flyweight – reduces the cost of creating and manipulating a large number of similar objects.
  • Proxy – provides a placeholder for another object to control access, reduce cost, and reduce complexity.

Behavioral Patterns

Behavioral patterns are concerned with algorithms and the assignment of responsibilities between
objects. Behavioral patterns describe not just patterns of objects or classes but also the patterns of
communication between them.

  • Chain of responsibility – delegates commands to a chain of processing objects.
  • Command – creates objects which encapsulate actions and parameters.
  • Interpreter – implements a specialized language.
  • Iterator – accesses the elements of an object sequentially without exposing its underlying representation.
  • Mediator – allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
  • Memento – provides the ability to restore an object to its previous state (undo).
  • Observer – is a publish/subscribe pattern which allows a number of observer objects to see an event.
  • State – allows an object to alter its behavior when its internal state changes.
  • Strategy – allows one of a family of algorithms to be selected on-the-fly at runtime.
  • Template method – defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
  • Visitor – separates an algorithm from an object structure by moving the hierarchy of methods into one object.

Not to forget, as time progressed there were a lot of design patterns which emerged and were published also. All those are not covered here, but you can google out to find many more patterns designed and implemented.

As we go forward, i will try to explain each patterns in detail with specific implementation on C++ and JAVA

Software Architect by profession, lazy programmer by choice.
Looking at the simplicity of problems and trying hard to find a complex solution for each of them.

“Opinions expressed are solely my own and do not express the views or opinions of my employer, family or friends”

Share if you liked this articleShare on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Email this to someone

So, What do you think?