Inheritance in OOP - should it be widely used?

Question

OOP

Good afternoon, dear programming
gurus, recently refreshed my understanding of the basic principles of OOP, and faced sharp criticism of inheritance as a basic principle. serious people highly recommend minimizing inheritance in your code. however, most books tout inheritance in every possible way and create long chains of inheritance to illustrate this principle. this topic is also liked to be abused in many universities by building long inheritance hierarchies.
Tell me, please, how often in real projects do you use inheritance from library and your own classes in the code. Or, according to another recommendation, you call a method of another object from your own class. Do you practice generalization of your own classes, or do you start coding classes from the most basic ones?

Answer 1

I'm not a guru, but in real projects they rule "Refactoring" by M. Fowler, "Perfect Code" by McConnell, "Techniques of Object-Oriented Design" by E. Gamma.
Inheritance, not inheritance - determined by the task and complexity of the code. Something beautiful and elegant is done by inheritance, somewhere it complicates everything on the contrary.

Answer 2

https://ru.wikipedia.org/wiki/SOLID_(object-orie... to be more precise -
https://ru.wikipedia.org/wiki/Substitution_Principle_...

Answer 3

Inheritance really should be avoided. In general, it is ideal to avoid it as if there is no inheritance at all, as if it is a cheat code when using which the proletariat kills a kitten.
Why is that? Let's imagine that we inherit everything and everything. Then the object will be ... Very capacious, because it is directly related to all ancestors (as well as ancestors - to all heirs). And the connectivity will be very, very strong, which will greatly complicate the architecture. It is often much more appropriate to simply include the object in the class (aggregate). First, it will greatly simplify the architecture. Secondly, the chain of constructors can be very long. And once again creating an object is not a good idea. Thirdly, by inheritance, we kind of declare that this class of objects is also this class. This is far from always true, which in the future will give rise to many crutches and pain. Whereas, having made a mistake with aggregation, we can always further expand to inheritance with several changes.

Answer 4

In my opinion, don't go to extremes. Add as many levels of hierarchy as you like. Example of redundant inheritance: liquid -> alcohol -> beer . If your application has only beer of different brands, then you can refuse the liquid and alcohol classes , but if you later add, for example, the vodka class , which will have common functionality with beer , then you can leave the alcohol class , the same also applies to the liquid class , if the application contains, for example, water or juice. The indisputable advantage of inheritance is polymorphism, so that when you give your little man in the application different drinks, it doesn’t matter if it’s juice or beer, he can use them according to the application. Always ask yourself the question: "Why?" when designing your application and avoid unnecessary abstractions and functionality.
PS The example is simplified to disgrace so that you can focus on the right points.

Answer 5

There are areas where inheritance is indispensable, for example, in GUI development, when classes have a lot in common - mouse events, sizes, coordinates, etc. In game programming, it's the same, game characters have a lot in common, so these things are best done through inheritance.
But you need to be able to combine this with the composition, i.e. not to shove everything into the parent class, but to take it out into separate classes. Thus, the parent class code will be simpler and inheritance will be easier to understand. For example, if monsters have behavior - AI, then there is no need to shove AI methods into the monster class, it is better to create a separate AI class for this and make it a separate field in the monster class.
Better yet, make AI as an external service that expects game objects as input. Thus, the monster class will not even know about the existence of AI, and thus the code will be easier to understand.

Answer 6

Hello. I can’t indicate real projects, but inheritance must be used when you need to extend a class as a kind. For example: the classes Dog, cat, etc. are inherited from the Animal class. You should also be aware of interfaces (java/c#) or multiple inheritance (c++,etc) that extend the capabilities of a class.
It would be nice to clarify a specific situation for an example or a programming language. However...
I'll tell you about Java, and in the comments tell me if this is used for all languages:
It must be understood that during the creation of an object (operator new, let's say new ChildClass() ), the constructor of the ChildClass class is first called. If ChildClass is a descendant of another class, such as ParentClass, then the ParentClass constructor is also called when the childClass object is created. Probably for this reason it is not advised to make long lines of inheritance.
Concerning the general object - any class is the successor of any general root class (for example, object).
UPD: yes, it seems that for all PLs the same principle of constructors works :)

Answer 7

Read about object oriented design and data oriented design. If you are writing a runtime application on limited memory, for example in gamedev. Then you have to get rid of abstractions, virtual functions and other things, for the sake of performance. If you have a database with JavaEE, then you are unlikely to have 100,500 levels of abstraction. Ultimately, how you write code is more important than what super-obfuscated abstraction you can pile up.

Answer 8

From a practical standpoint, deep inheritance hierarchies can make unit testing difficult. In addition, an unfortunate class hierarchy architecture may conflict with the Liskov substitution rule.
Also, in my opinion, this increases the coherence of the program, which is not always desirable.