There are many repetitive problems in the design of various information systems, these are usually repetitive problems, and design patterns have been created for these repetitive problems.
Due to the fact that specific design patterns have been created for specific problems, if we use a design pattern in the wrong way, it may end in a tragedy for us, it must be remembered that a design patern aren鈥檛 a problem, problem is wrong using and incomprehension.
Therefore, when in the introduction I said that Singleton is not recommended for use in most cases, among others because it breaks the principles of SOLID, Single responsibility (SRP) and Open-closed (OCP) and is stiff, not flexible and makes testing is difficult, but in some cases is a useful pattern. In the next lesson, I will describe Singleton in more detail.
They allow to separate the process of creating object instances from their definitions:
Patterns regarding problems with relations between many classes, solve typical problems of systems that have many classes, for example, so that binding between class are not too strong or not to use too much CPU resources:
They are responsible for sharing responsibility between classes, if someone knows the principles of Solid, in particular the first one will understand what鈥檚 going on.
And that would be enough of these more important design patterns, I will try to describe them all, there are also architectonic patterns such as MVC or MVVM, and design patterns for concurrent applications. I will try to describe them all in the next lessons on practical examples.
This content also you can find on my blog http://devman.pl/programtech/introduction-design-patterns/
If you recognise it as useful, share it with others so that others can also use it.
Leave upvote and follow and wait for next articles :) .
And that鈥檚 it when it comes to theories about design patterns, in the next lesson we will discuss Singleton.