Backend developer
Design patterns, most of them were analyzed by many smart brains yet. There are plenty of them, but they all have similar structure and became described. Every pattern can be defined fully as it follows:
Purpose
The main cause of use.
Problem description
What problems does it solves.
Range of application
It's an analysis of where it can be used, implemented - where it's useful.
Interactions
Visual schema of how it works with other components of project. These are UML diagrams for instance.
Implementation
More technical info on how to organize code.
Code samples
This is important for coders mainly.
Known implementations
Sometimes problem repeats and have already an implementation or more.
Similar versions
When design pattern is done, it may implicate others. One on another pattern, cause possibility to describe problem by exact patterns, not by code. More of those helps to understand the code structures for programmers.
When we want to extend class it’s simple, we just use extend keyword in our class definition to do that. But what if we don’t want to change class definition? Is there solution for that ? Yes, there is - decorator pattern. It helps to keep original object class with no change inside of it. It’s very useful if for some reason we don’t want to touch original class definition. Let’s take a look at code below, to understand it more.
Universal pattern for every solution - does it exist ? There is one interesting thing, that may be at some part. It is called “Picture that explains almost everything” and the concept is made by Mariusz Gil, specialist in design patterns and code brainstorming. He claims that it can solve almost every problem that is given. Here is the link to the picture on Mariusz Gil’s Twitter:
Another useful pattern is mentioned factory pattern. This one stands for creating objects of a different type but associated somehow. We could say that a request is done to the factory, and then it responds with the correct object or default object when the factory doesn’t know what to create. For example, the factory produces pizzas. It’s hard to create pizza with common object creation “new Margherita()” every time. Instead, we just use a static function with the desired pizza type. The code that handles this is much more editable and extendable.
Our approach
We take care of creating a good code with design patterns usage, so as a beneficent you gain valuable solutions. Thanks for your attention.