Design Patterns

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for functional programming languages, some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages.

Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm. for more..[1].

Classification and list

Creational patterns

These design patterns are all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.

Abstract Factory Design Pattern

Creates an instance of several families of classes

Abstract Factory patterns work around a super-factory which creates other factories. This factory is also called as factory of factories. This type of design pattern comes under creational pattern as this pattern provides one of the best ways to create an object.

Builder Design Pattern

Separates object construction from its representation

Builder design pattern is a creational design pattern like Factory Pattern and Abstract Factory Pattern.

Builder pattern was introduced to solve some of the problems with Factory and Abstract Factory design patterns when the Object contains a lot of attributes.

There are three major issues with Factory and Abstract Factory design patterns when the Object contains a lot of attributes.

• Too Many arguments to pass from client program to the Factory class that can be error prone because most of the time, the type of arguments are same and from client side its hard to maintain the order of the argument.
• Some of the parameters might be optional but in Factory pattern, we are forced to send all the parameters and optional parameters need to send as NULL.
• If the object is heavy and its creation is complex, then all that complexity will be part of Factory classes that is confusing.

We can solve the issues with large number of parameters by providing a constructor with required parameters and then different setter methods to set the optional parameters. The problem with this approach is that the Object state will be inconsistent until unless all the attributes are set explicitly.

Builder pattern solves the issue with large number of optional parameters and inconsistent state by providing a way to build the object step-by-step and provide a method that will actually return the final Object.

Factory Method Design Pattern

Creates an instance of several derived classes

Factory design pattern is used when we have a super class with multiple sub-classes and based on input, we need to return one of the sub-class. This pattern take out the responsibility of instantiation of a class from client program to the factory class.

Object Pool Design Pattern

Avoid expensive acquisition and release of resources by recycling objects that are no longer in use

Prototype Design Pattern

A fully initialized instance to be copied or cloned

Singleton Design Pattern

A class of which only a single instance can exist

Sometimes we need to have only one instance of our class for example a single DB connection shared by multiple objects as creating a separate DB connection for every object may be costly. Similarly, there can be a single configuration manager or error manager in an application that handles all problems instead of creating multiple managers.

The singleton pattern is a design pattern that restricts the instantiation of a class to one object.

• Constructor making private

class Singleton
{
    private static Singleton obj;
 
    // private constructor to force use of
    // getInstance() to create Singleton object
    private Singleton() {}
 
    public static Singleton getInstance()
    {
        if (obj==null)
            obj = new Singleton();
        return obj;
    }
}

If somebody will call instance.clone() method, will it create copy of our Singleton class?

So, if we are not implementing Cloneable interface in our Singleton class, then we do not require to prevent cloning. Java will do it for us.

Structural patterns

These design patterns are all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality.

Adapter Design Pattern

Adapter pattern works as a bridge between two incompatible interfaces. This type of design pattern comes under structural pattern as this pattern combines the capability of two independent interfaces.

Bridge Design Pattern

Bridge is used when we need to decouple an abstraction from its implementation so that the two can vary independently. This type of design pattern comes under structural pattern as this pattern decouples implementation class and abstract class by providing a bridge structure between them.

i.e.:We have a DrawAPI interface which is acting as a bridge implementer and concrete classes RedCircle, GreenCircle implementing the DrawAPI interface.

Filter Design Pattern

Filter pattern or Criteria pattern is a design pattern that enables developers to filter a set of objects using different criteria and chaining them in a decoupled way through logical operations. This type of design pattern comes under structural pattern as this pattern combines multiple criteria to obtain single criteria.

Composite Design Pattern

A tree structure of simple and composite objects

Composite pattern is used where we need to treat a group of objects in similar way as a single object. Composite pattern composes objects in term of a tree structure to represent part as well as whole hierarchy. This type of design pattern comes under structural pattern as this pattern creates a tree structure of group of objects.

Decorator Design Pattern

Add responsibilities to objects dynamically

Decorator pattern allows a user to add new functionality to an existing object without altering its structure. This type of design pattern comes under structural pattern as this pattern acts as a wrapper to existing class.

i.e.: car - basic car - sports car - luxury car implementation

Decorator class implements the component interface and it has a HAS-A relationship with the component interface. The component variable should be accessible to the child decorator classes, so we will make this variable protected.

Facade Design Pattern

A single class that represents an entire subsystem

Flyweight Design Pattern

A fine-grained instance used for efficient sharing

Private Class Data Design Pattern

Restricts accessor/mutator access

Proxy Design Pattern

An object representing another object

In proxy pattern, a class represents functionality of another class. This type of design pattern comes under structural pattern.

Behavioral patterns

These design patterns are all about Class's objects communication. Behavioral patterns are those patterns that are most specifically concerned with communication between objects.

Chain of Responsibility Design Pattern

A way of passing a request between a chain of objects

As the name suggests, the chain of responsibility pattern creates a chain of receiver objects for a request. This pattern decouples sender and receiver of a request based on type of request. This pattern comes under behavioral patterns.

In this pattern, normally each receiver contains reference to another receiver. If one object cannot handle the request then it passes the same to the next receiver and so on.

Logging to file, console etc..

Command Design Pattern

Encapsulate a command request as an object

Command pattern is a data driven design pattern and falls under behavioral pattern category. A request is wrapped under an object as command and passed to invoker object. Invoker object looks for the appropriate object which can handle this command and passes the command to the corresponding object which executes the command.

Interpreter Design Pattern

A way to include language elements in a program

Iterator Design Pattern

Sequentially access the elements of a collection

Mediator Design Pattern

Defines simplified communication between classes

Memento Design Pattern

Capture and restore an object's internal state

Null Object Design Pattern

Designed to act as a default value of an object

Observer Design Pattern

A way of notifying change to a number of classes

State Design Pattern

Alter an object's behavior when its state changes

Strategy Design Pattern

Strategy design pattern is one of the behavioral design pattern. Strategy pattern is used when we have multiple algorithm for a specific task and client decides the actual implementation to be used at runtime.

Strategy pattern is also known as Policy Pattern. We define multiple algorithms and let client application pass the algorithm to be used as a parameter.

For example: Shopping Cart where we have two payment strategies – using Credit Card or using PayPal.

Template method Design Pattern

Defer the exact steps of an algorithm to a subclass

Visitor Design Pattern

Defines a new operation to a class without change

Enterprise Integration Design Patterns

Editing Enterprise Integration Design Pattern(EIP) focuses on messaging patterns for enterprise application integration (EAI). Messaging makes it easier for programs to communicate across different programming environments (languages, compilers, and operating systems) because the only thing that each environment needs to understand is the common messaging format and protocol.

Messaging patterns define the means by which different elements in a message-passing system connect and communicate to enable interaction among objects within programs and among various types of software -- which may be written in different languages and exist on different platforms in multiple locations.[2]

First of all we should define EIPs and why we should use them. As the name implies, these are tested solutions for specific design problems encountered during many years in the development of IT systems. And what is all the more important is that they are technology-agnostic which means it does not matter what programming language or operating system you use. Patterns are divided into seven sections:

• Messaging Systems,
• Messaging Channels,
• Message Constructions,
• Message Routing,
• Message Transformation,
• Messaging endpoints,
• System management.