The nature of the inheritance of C + + programming criticism series

Both Eiffel and C + + provide a mechanism for multiple inheritance. But Java does not, because it believes that multiple inheritance can lead to many problems. However, Java provides an interface (interface) as a replacement mechanism, similar to the Protocol (Protocol) in Objective C. Sun claims that interfaces can provide all the features that multiple inheritance can provide.

Sun's assertion that "multiple inheritance brings many problems" is true, especially in C + +, where multiple inheritance is implemented. The simple reason that it seems that more inheritance would be easier than a single inheritance is now proving meaningless. For example, how do you develop a policy between data items that have the same name inherited from two classes? Are they compatible with each other? If so, should they be merged into one entity? If incompatible, how do you differentiate them? ...... Such a list can be listed for a long, long time.

Java's interface mechanism can also be used to implement multiple inheritance, but it also has a very important difference (compared to C + +): The interface in inheritance must be abstract. Because there is no implementation using the interface, this eliminates the possibility of choosing between different realities. Java allows the declaration of a constant number of segments in an interface. When multiple inheritance is required, they are merged into one entity, which does not result in ambiguity. But what happens when these constants have different values?

Since Java does not support multiple inheritance, we can not use the blend (mixin) as we did in C + + and Eiffel. Blending is an attribute that can put together different non-abstract functions from different classes to form a new complex class. For example, we might want to import some utility functions from different source code. However, we can also achieve the same effect by using combinations rather than inheritance, so this does not constitute an important attack on Java.

Eiffel does not import a separate interface mechanism when resolving multiple inheritance problems.

Some people may think that single inheritance is more elegant than multiple inheritance. This is a very special point of view.

BETA [Madsen 93] is one of those that says "more inheritance is not elegant": "There is not much inheritance in BETA, mainly because (for multiple inheritance) lacks a deep theoretical understanding, and the current (for multiple inheritance) recommendations is technically very complex. They cite flavors (a language that can mix classes together) as evidence. Compared with Madsen, multiple inheritance in flavors is related to its order, that is, inheriting from (A,b) and inheriting from (B,a) are different.

Ada95 is another language that does not support multiple inheritance. Ada95 supports single inheritance and calls it the markup type extension (tagged type extension).

Others argue that multiple inheritance can provide an elegant solution for problems under certain special models, and that the effort is worth it. Although the list of issues on multiple inheritance listed above is not perfect, it still shows that issues related to multiple inheritance can be systematically identified and can be gracefully resolved once the problem is confirmed. When [Sakkinen 92] reaches a very deep level for multiple inheritance research, it comes to the above definition.

The approach in Eiffel is that multiple inheritance raises interesting and challenging questions and then gracefully solves them. All the decisions that the programmer needs to make are limited to the inheritance clause of the class. It includes the use of renaming to ensure that many attributes of the same name derived from inheritance eventually become features with different names, new export Strategies for inherited features: redefining and Undefining, and select to eliminate ambiguity. In all cases, the compiler will do all this for us, so that the programmer has full control over the semantic clarity, regardless of the choice to use fork or join.

In C + +, there is a different mechanism for eliminating ambiguity relative to Eiffel. In Eiffel, in the renames clause, there must be a different name between attributes. In C + +, you can use the domain resolution operator ':: ' to differentiate between members. The advantage of Eiffel's approach is that ambiguity is eliminated in the statement. Eiffel's inheritance clause is a lot more complicated than C + +, but its code is simpler, firmer, and more resilient. This is the advantage of declaring a method as opposed to an operator method. In C + +, each time we encounter ambiguity between multiple members, we must use the domain resolution operator in the code. This makes the code messy, affects its ductility, and if there are other changes that can affect ambiguity, we may need to change the existing code in every place where ambiguity can occur.

According to section 12.8 of [Stroustrup 94], the ANSI Commission considered the use of renaming, but the proposal was blocked by a member of the committee, who insisted that the other members of the Committee should take two weeks to consider the issue properly. The example given in section 12.8 shows how the same effect can be achieved on the premise of not showing the renaming. The question is, if it all needs two weeks for the experts to think about how to do it, how much space is left for us?

The domain resolution operator is not only used to eliminate ambiguity in multiple inheritance. Because a well-designed language avoids ambiguity, the domain-resolution operator is an ugly, deepening complexity of the implementation approach.

In C + +, "How to declare a parent in multiple inheritance" is a complex issue. It affects the order in which constructors are invoked, and it can cause problems when programmers do want to go from subclasses to parent classes. However, we can also call this a bad program design style.

Another difference between C + + and Eiffel is the direct repeat inheritance, which is allowed in Eiffel:

Class B inherit A, a end but

Class B:public A, public a {};

But not be recognized by C + +.