Bertrand Meyer is mainly known as the founder of the term Openness / Closure Principle, which appeared in 1988 in his book Object-Oriented Software Construction. The idea was that once developed, a class implementation further only requires error correction, and new or modified functions require the creation of a new class. This new class can reuse the source class code through the inheritance mechanism. A derived subclass may or may not implement the interface of the source class.

That is, it turns out if we create, for example, a class Человек who has say methods поесть , поспать , попить . Then we will say in time we need to create a class Работник with methods - работать , получать зарплату and we need another method общаться , so what happens is that we cannot add this method общаться person, because it violates the principles of SOLID? But can we add it to the class Работник or any other Человека that is inherited by Человека ? ...

But this is incorrect? ... We can simply forget to add something to the base class, but after that it is impossible to modify it, but only to supplement and redefine the base class?

This principle will generate many unnecessary classes that inherit the base.

From Wikipedia:

Solid - principles, when applied together, are designed to increase the likelihood that a programmer will create a system that will be easy to maintain and expand over time [3]. SOLID principles are guidelines that can be applied while working on software to remove code smells by instructing a programmer to refactor the source code until it is clearly legible and extensible. It is part of an overall strategy for agile and adaptive development.

But this principle contradicts the concept (legibly written code and extensibility). Ie, if we already have a lot of created objects 'Man', and in the project we want them to now be able to communicate, after adding this method to another class, we must create all our objects on the basis of another class.

Ie according to the logic, according to the concept, according to common sense (in order not to rewrite the code) .. addition must be made in the class 'person'. + we get the opportunity to create people both having communication and those who cannot communicate - but this is a mistake in the design of the project code.

  • one
    It is probably necessary to create a class of the Человек общительный with the method of Общаться , which will be a descendant of the class of Человек and already inherit from it the Работника . - u_mulder
  • let's say for a year of using this person’s class, we may still need 1-2 methods at a time ... and so let's say 30 times .. is that creating 50-60 classes? ..... isn't it logical that if a person has a method to communicate .... then this method should be introduced precisely in the class "person" ... and not to create the class "sociable person" - especially adjectives are always methods or properties of an object, verbs are always methods and nouns are either properties of an object or the name of the object .... - Lesiuk Alexey
  • If you already have a Человек in the project, and you want to add the ability общаться in the middle of the project, this may be a mistake in the initial design. - VladD

1 answer 1

SOLID is not a dogma, but a recommendation. Usually, if you follow them, the code is easier to refine and test. But this may lead to the fact that the code can be more. The more you program, the more you understand how to better find a balance.

In addition to inheritance, there are other tools - for example, encapsulation, interfaces. I would make ОбщительныйИнтерфейс while from one method общаться . And the necessary heirs of Человека would implement this interface. Also, if many descendants of Человека общаются similar way, then, in order not to duplicate the code, I would take the logic of общения into a separate class and encapsulate it into the necessary Человеков .

  • And what difference is a dogma or a recommendation (principles are written in Wikipedia), if it is harmful to the design of the system, and not in favor? base class - easier? ...... Ok, suppose we have a class that implements various interfaces and we introduce a new "Sociable Interface" interface and ask that people now implement this interface, but this is again a violation of this principle. - Lesiuk Alexey
  • Some programmers believe that there are only three types of numbers - 0, 1 and infinity. In reality, you will rarely have more than 5 heirs. If you get 50 heirs and they are really needed (and you cannot do with some property of the object), then you have a very complex system and it is made by several people. When the code in different classes is good, because they can modify without interfering with each other, and when one changes its class, it is less likely to break the code of others. - luchaninov
  • In reality, the likelihood that we have created some kind of class, for example, "Man" and did not create all the necessary methods for him (for example, swim, go from point to point B, sleep, sit, run, etc.) - very big, therefore - the probability that N times (for example, tezhe 50) we will supplement this class with new methods - not so low .... (and it’s not 5 heirs that turn out to be but as many times as we forget to implement some method) ... - Lesiuk Alexey
  • Yes, I agree when the code in different classes is good, but only if it is necessary ... because it is a different implementation (by implementing another class) ... you have no effect on the code that has already been written and uses the base class ...... and what actually can be done by entering a new method into the base class ... which is not used anywhere else? - Lesiuk Alexey
  • one
    @LesyukAlexey in response to the question what can break the violation of this principle. Imagine the target audience of your project not as an end user but as a developer of something larger. You do not know what they will do with your library, for example, where your entities will be connected and how this will happen. Perhaps for example, the same work with class metadata will be used. And not taken into account the method suddenly appeared in the class will add trouble. But this is all the lyrics. All sorts of principles are the rules understood by the whole team working on the project before and after you. - Peter Slusar