Design Patterns Introduction
Ever seen a Blueprint of a building/vehicle/toys … ? In real world, a lot of time is invested into how to do something before actually start doing it. Planning should always come before implementation, same goes for software development also. Every famous software or website or app is made following some design patterns so that it’s easy to maintain, scale and add new features(whenever required).
Have you ever tried to read the open source projects of big organizations? Do you find them difficult to read or have you ever wondered why they have made so many classes, interfaces, used weird class names with words such as builder, factory, bridge, etc? All because of a simple reason that they follow design patterns and you don’t know much about them.
when we start to make a project, we just write code wherever we want to(without any planning). First, we don’t follow OOPS principles properly and Second, we don’t apply design patterns. In the end we are just pushing this huge amount of code.
It results in following problems:
1. multiple bugs pops up when we try to fix a single bug (a common problem)
2. difficult to scale
3. extremely hard to add a new feature
4. List goes on …
Design pattern is a general repeatable solution to a commonly occurring problem in software design. Remember that it is not a finished design that can be transformed directly into code. It is a template for how to solve a problem that can be used in many different situations. The idea is to speed up the development process by providing tested, proven development paradigm.
This story is only introduction to design patterns(as title says..duh). Each design pattern will be explained properly in a separate story and links will be added here.
Design Patterns give you a shared vocabulary with other developers. Once you’ve got the vocabulary you can more easily communicate with other developers and inspire those who don’t know patterns to start learning them. It allows you to say more with less. It becomes easy to work in team. It also elevates your thinking about architectures by letting you think at the pattern level, not the nitty gritty object level. Project becomes easy to maintain,scale.
Ques 1 : Aren’t libraries and frameworks also design patterns?
Well NO, You can’t just find a pattern and copy it into your program, the way you can with off-the-shelf functions or libraries. The pattern is not a specific piece of code, but a general concept for solving a particular problem. You can follow the pattern details and implement a solution that suits the realities of your own program.Ques 2 : So design patterns can be thought of as algorithms ? 😕
Patterns are often confused with algorithms, because both concepts describe typical solutions to some known problems. While an algorithm always defines a clear set of actions that can achieve some goal, a pattern is a more high-level description of a solution. The code of the same pattern applied to two different programs may be different.Ques3 : If I am good with OOPs principles, do I really need to think about Design Patterns? 😎
this is one of the true misunderstandings that by knowing the OO basics we are automatically going to be good at building flexible, reusable, and maintainable systems. Constructing OO systems that have these properties is not always obvious and has been discovered only through hard work. These, sometimes non-obvious ways have been collected into a set of patterns called “design patterns”.
Remember that the best way to use patterns is to load your brain with them and then recognize places in your designs and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse. Patterns are not invented, they are discovered !
Clap 👏 , Comment and share your valuable feedback and don’t forget to ask more questions in comment section below (if you have any 😉) ✌️
References:
1. https://sourcemaking.com/design_patterns
2. https://refactoring.guru/design-patterns/what-is-pattern
3. Head first design patterns book ( MUST READ !! )
