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

Builder Design Pattern

Separates object construction from its representation

Factory Method Design Pattern

Creates an instance of several derived classes

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;
    }
}

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

Match interfaces of different classes

Bridge Design Pattern

Separates an object’s interface from its implementation

Composite Design Pattern

A tree structure of simple and composite objects

Decorator Design Pattern

Add responsibilities to objects dynamically

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

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

Command Design Pattern

Encapsulate a command request as an object

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.