Idle say inherit

Inheritance is already an old topic, but recently it has been discussed in some places, and there are some ideas about it, which has formed this article.

Is it good to inherit?

The classic oo theory says: Inheritance is one of the three cornerstones of object-oriented.

Modern oo theory says: The combination is better than inheritance.

These two statements clearly clash with each other. If the combination is superior to inheritance, why does the combination not replace inheritance as the cornerstone of OO? Which statement makes more sense?

To this question, simply saying which one is better than which is actually not very meaningful. We should look at the historical point of view of technological development, the two kinds of statements are produced in the period, what is the background of their formation, in order to have a more profound understanding of this problem.

Object-oriented thinking was formed in the 70 's, but the real popularity of the software development camp was in the late 80 and early 90. Coincidentally, this time is also the Windows 3.x represented by the rise of the graphics operating system era. So the main problem facing the object-oriented was: how to encapsulate the development of the graphical interface with OO theory? Many of the important early OO ideas were formed during this period, including the use of inheritance.

Let's consider the characteristics of the graphical interface. It's easy to see that this area is really good for using inheritance, because graphical objects are inherently is-a. For example, all image objects are Windows, all dialog boxes are dialog, all buttons are button, and so on. So the result we can see is that all of the graphical interface frameworks use inheritance in large numbers, and the level of inheritance is usually very deep. For example, the following figure is the inheritance of the most important interface class--window in WPF, and its inheritance level is 9 layers deep!

All graphical frameworks have almost no exception in terms of inheritance. Java Swing has a lighter depth of inheritance because of the greater use of MVC in the graphics framework, but the main JFrame class inherits the depth of 6 layers:

So we should understand why early OO theory has to take inheritance as a cornerstone of object-oriented. Because of the narrow scope of software development at that time, many developers based on their own experience in the field of graphics identified: Inheritance is an essential foundation of OO, and should be used as much as possible.

With the development of history, software development has gradually entered the two-layer and three-tier era. Programmers found that the inheritance that was handy in desktop applications suddenly became less useful. Why, then?

One of the reasons: one of the main tasks of the two-tier and three-tier development is to model entities. In reality, most of the entities are relatively independent, and the relationship between them is more manifested in the association between the entities, rather than the subordinate relationship;

The second reason is the important realistic problem: the relational database, one of the main material bases of multilayer development, cannot describe the inheritance relationship very naturally. In fact, this is one of the important reasons for ORM to appear. But even the best ORM tool today, it's still very complicated to describe the inheritance relationship in the database. This forced the programmer to give up the inheritance to a considerable extent;

The third reason: layered development approach is becoming popular, and inheritance caused by the relationship between the class is not conducive to layering.

For these reasons, it should be easy to understand why modern OO theories recommend combinations rather than inheritance.

So is modern oo theory perfect for inheritance? I do not think so. In fact, I think there is a problem of ignoring inheritance in modern oo theory, and many theoretical books simply tell us to use the combination of precedence, and we simply do not tell when and when we should use inheritance reasonably. It is also undesirable to jump from an overused inheritance of early oo to another extreme.