Software design patterns – Part 1: Intro, Types & Use cases
A design pattern represents a reusable solution/best practices for common problems in the software designs. These are language-independent and represent ideas for approaching the problems with a proven set of methods being widely accepted.
Design patterns can speed up the development process by providing tested and proven paradigms. In many of the software designs, some issues may not be visible till the later stages of implementation. Using design patterns can reduce this risk as they cover the known issues using standard structures that most of the developers and the architects understand.
The software design patterns are broadly classified into three different types
Creational
These are the patterns related to object creation and class instantiation. These could be further classified as “class creational” and “object creational” patterns. Class creational uses inheritance for instantiation while the object-creational uses delegation.
Patterns
Use cases
- Best practices for the creation of expensive objects ( DB connection or socket connection )
- Limiting of the instance creation
- Standard interface for creating different types of objects based on implementation
Structural
These patterns refer to the organizing or composing of different objects and classes to form complex new objects or functionality.
Patterns
Use cases
- Best practices for generating loosely coupled interfaces that communicate with each other.
- Designing services that talk to different systems and creating a unified interface for the base system ( Integration layer ) .
- Creating a common interface between two non-compatible systems that need to establish a relationship.
Behavioural
Behavioral patterns identify common communication patterns between the objects.
Patterns
- Chain of responsibility
- Command
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Template method
- Visitor
Use cases
- The case where the developer is required to allow extension of functionality but cannot change the base source code. We could use a Template pattern in this case.
- Creating reactive modules that can observe for changes on one module and react to it.
We will be looking at each of the design patterns in detail in the upcoming posts and covering each one of them.