Apply the KISS principle to the design principles themselves.
(Update: replaced the picture with a more neutral one)
A colleague mentioned in the conversation the principle of "Convention over configuration", and I thought, damn, this is probably something cool, you need to study, read articles, and then lag behind life.
What was my surprise that all the explanation is placed in one phrase "Use defaults, which you can redefine if you want."
And then I thought that there are a lot of principles that are pronounced with an intelligent face and a wrinkled forehead, although in fact there is nothing complicated there. Many of them can be explained literally in one phrase. Well, maybe a paragraph of text or a practical example. On the fingers, in short. In general, it often happens that you explain to someone in a minute what you yourself have studied for quite some time. And some details grow only later, the main thing is to get the "key".
In the end, I tried to make such a label. We can say a kind of Russian-Chinese phrasebook:
| Value | Transfer |
|---|---|
| Kiss "Keep it short and simple", “Keep it simple, stupid!” Etc. | Do not complicate the code without a good reason |
| Encapsulation | We do not need to know what is inside the object, just use public methods. So we simplify to understand complex systems and reduce the connectedness of objects with each other. |
| Convention over configuration | Instead of a config describing everything, it is better to use defaults, which, if desired, can be redefined in the config. |
| Barbara Liskov substitution principle The original wording: " ... Let q (x) be a property true with respect to objects x of some type T. Then q (y) must also be true for objects y of type S, where S is a subtype of type T ... ") | The behavior of the heir class must not conflict with the behavior specified by the parent class. So that you can easily substitute an object of the class Dog where an object of the class Animal is expected |
| Principle of sole responsibility | A class must do one thing. |
| Interface separation principle "... Customers should not depend on methods that they do not use ..." | In arguments of a constructor or a method, one should not expect an object with a lot of unnecessary details if the class needs only a small specific object to work with or even a single integer. And definitely it is not necessary to push the container of dependences in all classes. |
| High cohesion | A class must do one thing :). If you see that some methods are used separately, separately from others, with some data of your own, then you do not have high cohesion. It may be worth dividing the class into parts or transferring some of the methods to something else. |
| Low coupling | Classes should be tied as little as possible to other classes, especially their contents. Do not control the paws of the dog, manage the dog |
| Dependency Inversion Principle "... The modules of the upper levels should not depend on the modules of the lower levels. Both types of modules should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions ..." | Classes should be as small as possible tied to other classes :) For the flexibility of the code in the arguments of the constructor / method, you need to make interfaces or abstract classes, rather than specific classes. |
| Principle of openness / closeness "... Program entities (classes, modules, functions, etc.) should be open for expansion, but closed for change ..." | New functionality should be added by adding a new class, rather than adding a new if branch to an existing class that does everything. |
| Yagni “You aren't gonna need it,” “You won't need it.” | Do not do what they did not ask. The “may need in the future” approach greatly complicates the code and support |
If there is a desire to add, correct or argue - as usual, write in the comments
')
Source: https://habr.com/ru/post/347242/
All Articles