Diamond problem

A diamond class inheritance diagram.

In object-oriented programming languages with multiple inheritance and knowledge organization, the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?

For example, in the context of GUI software development, a class Button may inherit from both classes Rectangle (for appearance) and Clickable (for functionality/input handling), and classes Rectangle and Clickable both inherit from the Object class. Now if the equals method is called for a Button object and there is no such method in the Button class but there is an overridden equals method in both Rectangle and Clickable, which method should be eventually called?

It is called the "diamond problem" because of the shape of the class inheritance diagram in this situation. In this article, class A is at the top, both B and C separately beneath it, and D joins the two together at the bottom to form a diamond shape.

Approaches

Different programming languages have addressed this problem in different ways:

• C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" (for example, "class B : virtual public A"), C++ takes special care to only create one A object, and uses of A's members work correctly. If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A. Please note that nonvirtual derivation of A in this case will be useless as direct access to any part of class A from class D will practically always end up with compile error.
• Common Lisp attempts to provide both reasonable default behavior and the ability to override it. By default, the method with the most specific argument classes is chosen; then in the order in which parent classes are named in the subclass definition. However, the programmer can override this, by giving a specific method resolution order or stating a rule for combining methods.
• Eiffel handles this situation by select and rename directives, where the ancestors' methods to use in a descendant are explicitly specified. This allows the methods of the base class to be shared between its descendants or to even give each of them a separate copy of the base class.
• Perl and Io handle this by specifying the inheritance classes as an ordered list. In the above ambiguity, class B and its ancestors would be checked before class C and its ancestors, so the method in A would be inherited through B. In Perl, this behavior can be overridden using the mro or other modules to use C3 linearization or other algorithms.
• Python had to deal with this upon the introduction of new-style classes, all of which have a common ancestor, object. Python creates a list of a classes using the C3 linearization algorithm. That algorithm enforces two constraints: children precede their parents and if a class inherits from multiple classes, they are kept in the order specified in the tuple of base classes. Thus, the method resolution order is: D, B, C, A.^[1][2]
• Scala resolves method names using a right-first depth-first search of extended 'traits', before eliminating all but the last occurrence of each module in the resulting list. So, the resolution order is: [D, C, A, B, A], which reduces down to [D, C, B, A].
• JavaFX Script in version 1.2 allows multiple inheritance through the use of mixins. In case of conflict, the compiler prohibits the direct usage of the ambiguous variable or function. Each inherited member can still be accessed by casting the object to the mixin of interest, e.g. (individual as Person).printInfo();.

Other examples

Languages that allow only single inheritance (such as Ada, Ruby, Objective-C, PHP, C#, Delphi/Free Pascal and Java) allow the multiple inheritance of interfaces (called protocols in Objective-C). Interfaces are essentially abstract base classes with all abstract methods and no data members. The problem is therefore less likely since there is in most cases only one implementation of a specific method or property. Ambiguity can arise when multiple interfaces declare the same methods and the class defines them separately. See explicit interfaces.

The diamond problem is not limited to inheritance. It also arises in languages such as C and C++ when header files A, B, C, and D #include one another in a diamond as above and separate precompiled headers are created from B and C. If these two precompiled headers are combined, declarations in A are duplicated and the #ifndef include guard is ineffective. It also is found when composing middleware stacks; for example, if A is a database and B and C are caches, D may ask both B and C to commit a transaction, resulting in duplicate commit calls to A.

References

1. ^ http://www.python.org/download/releases/2.2.3/descrintro/#mro
2. ^ http://rhettinger.wordpress.com/2011/05/26/super-considered-super/

Bibliography

• Eddy Truyen, Wouter Joosen, Bo Nørregaard Jørgensen, Pierre Verbaeten (2004). "A Generalization and Solution to the Common Ancestor Dilemma Problem in Delegation-Based Object Systems". Proceedings of the 2004 Dynamic Aspects Workshop (103–119). http://www.cs.kuleuven.ac.be/~eddy/PUBLICATIONS/DAW2004.pdf. 

External links