Inheritance and composition

Original link: http://www.cnblogs.com/shuhari/archive/2009/06/04/inherit_thinking.html

Is it good to inherit?

The classical oo theory says: Inheritance is one of the three cornerstones of object-oriented.
Modern OO theory says that the combination is better than inheritance.

These two statements clearly clash with each other. If the combination is better than inheritance, then why does the combination not replace inheritance as the cornerstone of OO? Which one is more reasonable?
For this question, it is not very meaningful to say which is better than which. We should see from the historical point of view of technological development, when these two statements were produced, and what background they formed, in order to have a more profound understanding of the problem.

The idea of object-oriented was formed in the 70 's, but the real popularity in the software development camp was in the late 80 and the early 90. Coincidentally, this time is also the Windows 3.x as a representative of the emergence of the graphics operating system era. So the main problem faced by object-oriented at the time is: how to encapsulate the development of 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 features of the one-shape interface. It's easy to see that this field is really good for using inheritance, because graphical objects inherently have is-a relationships. For example, all Image objects are window, 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 hierarchy of inheritance is usually very deep. For example, it is the inheritance relationship of the most important interface class--window in WPF, which has a hierarchy of 9 levels deep!

All graphics frames have almost no exceptions in terms of inheritance. Java Swing has a more intensive use of MVC for graphics frames, so the depth of inheritance is shallower, but the main JFrame class inherits depth of 6 levels:

At this point, we should understand why early OO theory will inherit inheritance as the cornerstone of object-oriented. Because the field of software development at that time is still relatively narrow, so many developers according to their own experience in the field of graphics development: Inheritance is an essential foundation for OO, and should be used as much as possible.

With the development of history, software development has gradually entered the two-and three-story era. Programmers find that the legacy of handy inheritance in desktop applications is suddenly less useful. Why is it?
One reason: 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, the relationship between them is more manifested as the association between entities, rather than the subordinate relationship;
Reason two, very important reality problem: one of the main material bases of multi-layer development--relational database, can not 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 now, it is still very complex to describe the inheritance relationship in the database. This forces the programmer to give up the inheritance to a considerable extent;
The third reason: layered development approach is gradually popular, and inheritance caused by the coupling of the generic relationship is very detrimental to stratification.

For these reasons, it is easy to understand why modern OO theory is more recommended than inherited.
So is the modern OO theory perfect for the idea of succession? I don't think so either. In fact, I think that there is a problem of ignoring inheritance in modern oo theory, and many theoretical books simply tell us to use the combination of priority, and we simply do not tell us when we should use inheritance rationally and when not to use it. It is not advisable to jump from an early oo over-use inheritance to another extreme.

Next class I want to talk about some common misconceptions about inheritance.

1. "Combination is better than inheritance." "
In the general sense, this is true, but the problem is that it is too brief. It does not tell us what the combination is better than inheritance. A natural question is, if the combination is better than inheritance in any case, is there any need for inheritance?


In some cases inheritance is actually better than the combination. Back to the example of the graphical interface, the button inherits from window (which is the term for MFC earlier, and in WINFORM/WPF's classification, the button inherits from the Control,window typically used to define the top-level window), which is no problem, If you must use a combination to implement the button, it will lead to unnecessary complexity. The reason the inheritance is better in this case is that there is a definite is-a relationship here (Button is a Window). So we can draw a conclusion: if there is a definite is-a relationship in semantics, consider using inheritance; if not, use the combination.

It should be explained that this conclusion is not complete, and I will continue to talk about it later.

2. "The purpose of inheritance is to reuse. "
This is a false statement, but the prevalence of this myth is simply surprising. Inheritance is not for reuse, the fundamental purpose of inheritance is to better model the real world, easy to reuse is only an inevitable result of excellent models. We cannot reversing, in particular, that we should not inherit for the purpose of reuse.

Give a realistic example. Cars can re-use some of the features of the wheel (such as run and stop), so should we let the car inherit from the wheel? I see that there are really some people that are modeled like that. But logically think about it, it is very unreasonable, the car is not a wheel. We've built a wrong model, which will cost us a lot later-for example, what if we want the car to change wheels? Had to be dumbfounded.

Again, the purpose of inheritance is not reuse, and inheritance should not be used in order to be reusable. You should try to build a logical model, and you should not distort the model just for convenience.

3. As long as there is a is-a relationship, you should use inheritance
In the 1th I said: If there is a definite is-a relationship in semantics, consider using inheritance; if not, use the combination. I also added that this conclusion is not complete, and this explains why.

Let's start with an example. Here's a classic example that many OO books will mention:

In this model, both sales and manager are employee, but the way they calculate salaries is different. Different pay methods can be implemented by overloading the Getsalary () method.

Is there a problem with such a classic example? Yes! We can think, "What happens if an employee is promoted to manager?" ”

Here's the problem. In Oo world, the type that an object belongs to is the essential attribute of the object, and any object cannot change its own category during life. But the identity of the object in reality can be changed many times. Here we can find a major problem with inheritance: Once the identity of an object changes, the hierarchy of inheritance collapses completely.

So why do you use inheritance in the graphical interface? Because the object identity of the graphical interface domain is fairly stable. The button is the button, and it doesn't suddenly become a top-level window. So there's no problem with using inheritance here. However, inheritance is not appropriate for situations where the type is variable.

From the point of view of modeling, we can also understand: is the sales or manager, not a person's essential attributes, it is variable. The essential attribute of a person is only his own (name, gender is in fact variable). We are not able to apply non-essential attributes to the inheritance hierarchy.

So the above conclusion should be complete: if there is a definite is-a relationship in semantics, and the relationship is stable and unchanging, consider using inheritance, if there is no is-a relationship, or if the relationship is mutable, use a combination.

We can use the policy model to refactor the above example into use combinations, as shown in:

From the above conclusions we can see that the use of inheritance is indeed subject to many limitations, and in many cases it is indeed a combination superior to inheritance. But it is too dogmatic to think that the combination must be better than the succession, regardless of the circumstances. There is only one reasonable approach: concrete analysis of specific problems.

Inheritance and composition (RPM)