Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time.
Why should we use them?
Design patterns are, by principle, well-thought out solutions to programming problems. Many programmers have encountered these problems before, and have used these ‘solutions’ to remedy them. If someone faces the similar problem why not to use the same solution instead of creating another solution. This will save time and money.
Types of Design Patterns
As per the design pattern reference book Design Patterns – Elements of Reusable Object-Oriented Software , there are 23 design patterns which can be classified in three categories: Creational, Structural and Behavioral patterns.
These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. These design patterns are all about class instantiation.
- Abstract Factory
Creates an instance of several families of classes
Separates object construction from its representation
- Factory Method
Creates an instance of several derived classes
- Object Pool
Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
A fully initialized instance to be copied or cloned
A class of which only a single instance can exist
These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
Match interfaces of different classes
Separates an object’s interface from its implementation
A tree structure of simple and composite objects
Add responsibilities to objects dynamically
A single class that represents an entire subsystem
A fine-grained instance used for efficient sharing
- Private Class Data
Restricts accessor/mutator access
An object representing another object
These design patterns are specifically concerned with communication between objects and have these objects behave.
- Chain of responsibility
A way of passing a request between a chain of objects
Encapsulate a command request as an object
A way to include language elements in a program
Sequentially access the elements of a collection
Defines simplified communication between classes
Capture and restore an object’s internal state
- Null Object
Designed to act as a default value of an object
A way of notifying change to a number of classes
Alter an object’s behavior when its state changes
Encapsulates an algorithm inside a class
- Template method
Defer the exact steps of an algorithm to a subclass
Defines a new operation to a class without change