Table of Contents
Background
Design patterns are solutions to very common problems in coding. They serve as a blueprint of common solutions to coding. Design patterns are not actual code though.
During software development, patterns cannot be copy pasted like the other functions/code. Patterns are a high level and general concept of solving a problem efficiently. Due to this fact, the code of the same pattern, if implemented in two different programs may be different
How is a design pattern made?
In a very simplistic view, when a pattern emerges in a lot of places while coding, someone give it a name and adds it to the list of existing patterns.
Originally, the first book published in 1994 was titled Design Patterns: Elements of Reusable Object Oriented Software . The authors of this book described the patterns and applied it to programming. After this, a lot of design patterns have emerged both in object oriented programming paradigm and also in other programming paradigms.
Why study design patterns?
The reality is that these patterns come intuitively also to a lot of great programmers who don’t know this pattern exclusively. This is also true that you don’t need to fit every problem into a paradigm. So why study design paradigms anyway?
- Think of design patterns as a reference guide for solving common object oriented paradigm challenges. Frankly, if one doesn’t know whether some solution already exists to a common problem, the time taken to overcome the challenge will be higher and also might be prone to failures. Hence, even the familiarity to these design patterns will enable a programmer to reduce the time in finding the solution and spend more time building on top of the existing solution to make it less prone to errors.
- Knowing the patterns will help you gain a broader perspective of solution building as most programmers spend a lot of time devising solutions ultimately to find that it fails when the scope widens.
- It serves as a standardization tool across developers anywhere in the world
Will design patterns solve all object oriented design patterns?
It really depends on your use case. In the process of developing quality software, use case is what governs almost every part of the choices. One axiom is to keep the design and implementation as simple as possible. So unless it’s absolutely required, let’s try not to over complicate the issues.
While working the coding language, one should be mindful of the paradigms that the program supports. It might help you completely avoid the use of certain patterns. For eg, Strategy pattern implementation can be completely avoided by using just an anonymous/lambda function. Java did not have this feature until Java 8. So version of java prior to Java 8 would be forced to use the strategy pattern if the usecase demands it but java versions post java 8 would just utilize the lambda function
The best way in which a design pattern can be used is :
- Identify the problem
- Check if there is any design pattern that is close to solving the problem
- Modify the design pattern to customize to your need if it exists or write your own implementation if no design pattern exists that solves your problem
DONOT IDENTIFY the design pattern first and then try to fit the problem into it. It may lead to unnecessary complicated code. This thought process actually gives rise to dogma.
Design Patterns Classification
They are mostly classified based on the intent or purpose. There are 3 main groups of patterns.
Creational Patterns
Patterns under this category provide the mechanism for object and class creation and reuse of existing code. Class-creation patterns use inheritance in the process of instantiation and Object-creation patterns use delegation effectively to achieve the desired action. Read more …
Structural Patterns
Patterns under this category explain how classes and objects are put together into larger entities while these entities remain efficient, flexible and robust. Read more …
Behavioral patterns
These patterns generally govern the responsibility assignment between two or more objects and the algorithms used in the process.. Read More …