Design Patterns : Introduction

Next post in the series – Design Patterns : Observer Pattern

For a long time I was thinking about starting a series of posts on some topic. I thought why not start with the most ‘over-rated’ topic in software development. Hence, this is the introductory post in the series of posts on ‘Design Patterns’.

There is a huge buzz around this word ‘design patterns’ with some people further glorifying it as the bread and butter of software development. They go on to the extent of saying that a software application that does not use a design pattern is not a good software. They would further go ahead and try to modify the problem itself to fit into some design pattern. 😀 But frankly speaking, the decision whether to use a design pattern or not is more dependent on the problem that is there at hand.

In simple words, design patterns are nothing but recurring solutions to recurring problems in software architecture. Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems. It also improves code readability for coders and architects who are familiar with the patterns. But doing so has some disadvantages as well. In order to achieve flexibility, design patterns usually introduce additional levels of indirection, which, in some cases may result in a performance hit in the applications.

Design Patterns were originally grouped into three categories: Creational, Structural and Behavioral and were described using the concepts of delegation, aggregation and consultation. Later a new classification of design pattern was added called the architectural design pattern. A well-known example of this classification of design pattern is the MVC design pattern. In this post let us list down a few common design patterns from each of the categories.

Creational Design Patterns

  • Abstract Factory: Creates an instance of several families of classes
  • Builder: Separates object construction from its representation
  • Factory: Creates an instance of several derived classes
  • Prototype: A fully initialized instance to be copied or cloned
  • Singleton: Only one instance of this class can exist

Structural Design Patterns

  • Adapter: Matches interfaces of different classes
  • Bridge: Separates an object’s interface from its implementation
  • Composite: A tree structure of simple and composite objects
  • Decorator: Adds responsibilities to objects dynamically
  • Façade: A single class that represents an entire subsystem
  • Flyweight: A fine-grained instance used for efficient sharing
  • Proxy: An object representing another object

Behavioral Design Patterns

  • Mediator: Defines simplified communication between classes
  • Memento: Captures and restores an object’s internal state
  • Interpreter: A way to include language elements in a program
  • Iterator: Sequentially access the elements of a collection
  • Chain of Responsibility: A way of passing a request between a chain of objects
  • Command: Encapsulates a command request as an object
  • State: Alters an object’s behavior when its state changes
  • Strategy: Encapsulates an algorithm inside a class
  • Observer: A way of notifying change to a number of classes
  • Template Method: Defer the exact steps of an algorithm to a subclass
  • Visitor: Defines a new operation to a class without change

The concept of design patterns has also been criticized in several ways. Sometimes it is said that design patterns may just be a sign of missing features in some programming languages. Moreover, another downside of design patterns is that their inappropriate use might unnecessarily increase complexity and decrease application performance.

Next post in the series – Design Patterns : Observer Pattern




2 thoughts on “Design Patterns : Introduction

  1. Pingback: Design Patterns : Observer Pattern | Harshit Shrivastava

  2. Pingback: Design Patterns : Singleton Pattern | Harshit Shrivastava

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s