Design patterns?

Question

PHP

I re-read a large number of articles about patterns and their use in php, but I still didn’t understand why they are used in the examples given, and after reading the next article, the only question left for me is “why?”, also very often in different articles there are no examples nothing in common, that's what pisses me off the most. I don't even know what to do or how to live. Can you advise some books, where not just some abstract examples are shown, but more situations are explained where these damn patterns can be applied.
So far, for me, patterns are code that is complicated by just for lulz.
PS You have the opportunity to prevent the suicide of an unlucky programmer.

Answer 1

Patterns are real tools that allow you to achieve the implementation of the concept of object-oriented design and the principles of SOLID
Link to SOLID
This is an important concept, without it it will be difficult to build an effective and ergonomic tool even on a good framework.
One of the most common examples for me is an example of the "Principle of open / closed" principle, when a class that describes a certain entity (for example, a comment model) describes only its basic purposes (creation, deletion, editing), while mechanisms such as moderation , attaching files, likes , is implemented by other classes and "fastened" to the model class through interfaces and inheritance / traits / mixins
At the same time:
1) The code of the "Comment" class does not change in any way (except for connecting the interface) and in the future we will add behaviors without changing the class + system stability, flexibility
2) Each class has its own clear purpose + ease of modification, order
3) Comments inherit some behavior, by connection of behavior, but any other classes - entities (posts, blogs, etc.) can also come, that is, the interface and implementation of likes is universal, and all the functionality of likes is only (strictly!!!) in one place + ease of modification, Universality, stability , intuitive
From wikipedia :
Signs of a bad
From there about SOLID The
following five SOLID principles help to get rid of the "signs of a bad design"[4]:
The Single Responsibility Principle
There is only one reason that leads to the appearance of a class.
The Open Closed Principle
"Software entities ... should be open for extension, but closed for modification."
The Liskov Substitution Principle
"Objects in a program should be replaceable with instances of their subtypes without changing the correct execution of the program."
Interface separation principle(The Interface Segregation Principle)
"many client-specific interfaces are better than one general-purpose interface."
The Dependency Inversion Principle
“Dependence on Abstractions. There is no dependence on anything specific.

Answer 2

The point is that 2 developers are talking (one new to the team came) and he asks like this: how does one part of the system find out about new users? Another says: we made an Observer there and the developer, without seeing the code, already roughly understands how everything works! Because he knows how the Observer pattern works.
Another thing is that the pattern itself can be controversial and it is not clear whether they benefited from it or not, but this is another question...

Answer 3

Using patterns makes the code more structured. And more understandable to another programmer familiar with the same patterns. Those. there will be no need to think "where did the blah-blah-blah method get stuck" if everything is subject to the general logic of some pattern.
Additionally, it is possible (depending on the pattern) to add all sorts of goodies such as facilitating the addition of new functionality.

Answer 4

The most important resource is time. Patterns can save it. Or maybe vice versa. It all depends on experience. You can come up with them yourself when you discover certain sequences of actions in your life. It's not just about programming. Sometimes the pattern can be changed to fit your needs. It's just a kind of pattern wound on the subject area.

Answer 5

Patterns are not code. Patterns are an idea. And the code (implementation) can be different. Therefore, wherever you see code, this is a particular example of a pattern.

Answer 6

I am currently actively studying this topic.
Since the problem is with the very understanding of why they are needed, then I can advise you to work with a development team (> 3 person) on some large, constantly evolving project, then the understanding of the need for object design will come to you when you start drowning in unsupported code. Most frameworks by the way in the box offer an implementation option.
Similarly, when you are working alone on a simple project, and you are completely sure that it will not scale in the future, then there is nothing to inflate it, especially if the budget does not allow.

Answer 7

The trouble is that when learning patterns, the student inevitably gets the feeling that patterns are about how to write classes.
And patterns, in fact, allow you to write classes quite freely. They don't declare anything at all about class internals.
Patterns are descriptions of interactions between classes . A way to make these interactions, on the one hand, minimal so as not to break class encapsulation, and on the other hand, obvious and simple so that the programmer does not need to understand the nuances of this interaction.
That's why "small sample patterns" are meaningless - they don't play in small code.
And it's just as pointless to discuss the implementation of concrete classes that are interconnected by a pattern. It can be arbitrary, as long as the excess does not stick out.

Answer 8

Here is a video on the topic: https://www.youtube.com/watch?v=wX6BBaQZpzE
Patterns you already use consciously or unconsciously.
Patterns are something natural, there is a specific situation, there is a specific method for solving this situation.

Answer 9

when studying patterns, you need to understand that they can simplify the system, or they can spoil it so that no one will understand.)
in general, the goal is to break the system into parts, make everything as simple as possible, and make the parts as independent as possible.
a common disease after studying a template is to shove it everywhere. sometimes it turns out like a cannon on sparrows.
patterns are not things in and of themselves. they are sometimes needed to implement, for example, solid principles.

Answer 10

I came across patterns while studying Symfony. And it becomes clear how they work and what problem they solve.

Answer 11

Can you recommend some books

As for books, in my opinion, Matt Zandstra explains quite well different patterns in "PHP: Objects, Patterns and Programming Methods. 4th Edition"
If you haven't read it, you can try it. He describes there both patterns from the famous gang of 4, and corporate application templates.

Answer 12

Patterns are the experience of pain, suffering and sweat of a huge number of the best developers and programmers. It can be said that the patterns, like the rules of the road, are in some way written in blood.
On small and even medium-sized projects in terms of complexity and code size, especially if you cut into one, most of the patterns will not be obvious, somewhere even not useful. Another thing is a large enterprise project that has been living for decades, on which there is not a weak staff turnover. Such monstrous things are simply impossible to build without patterns. Actually, most of the patterns came out from there.
Therefore, in my opinion, the best way to learn patterns is to get into an enterprise environment where you simply cannot not use them. Literally in a year and a half, you will begin to think in patterns.
And so, on his own, but on trifles, this is pampering and not serious.