Developer Zone

Advanced Software Development with MATLAB

This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

The Diamond of Breadth 2

Posted by Andy Campbell,

Sometimes, Java® bugs me.

Don't get me wrong, in many ways it is a beautiful language full of elegant structure and all the tools you need to help drive robust architectures. However, the flipside is that this structure and rigid set of rules add layers of complexity and requires mundane, un-interesting passion-zapping boiler plate code to accomplish the interfaces you want while also achieving the code reuse that keeps you productive.

On the other hand, sometimes C++ scares me.

C++ is much closer to the metal, and allows you to shoot yourself in the foot if you can't recite every section of the C++ standard verbatim or know precisely how each compiler implements the standard. This is fantastic, allowing you full access and full control as to how the streaming bits of ones and zeros dance on the hardware, and simultaneously devastating when these same ones and zeros crash and burn instead.

One interesting case study comparing these approaches is the (in)famous diamond of death problem with multiple inheritance. C++ supports multiple inheritance, and it is very dangerous when it is encountered due to the default C++ semantics. Take the following simple diamond structure:

By default, the underlying C++ objects that are created result in actually two instances of A as seen below, one for each path through the inheritance. This can cause a world of pain, especially when casting at runtime and the object is sliced in unforeseen and unexpected ways. When there are two truths for what A is you can also see how you can get into an inconsistent state, where if you change a property through a pointer to B and access that property through a pointer to C you are actually setting and accessing two different copies of that property!

Now, as we learn more C++ there are ways to avoid this ambiguity, but in general I think its a fair claim that using multiple inheritance in C++ is an advanced maneuver that can be fraught with peril, and you had better know what you are doing fully and completely in order to avoid falling into some of these dangerous pitfalls. The resulting culture has been to avoid multiple inheritance, largely due to this behavior of the diamond problem.

In fact, this problem has had a direct impact on the design of languages like Java and C# which specifically prohibit multiple inheritance of properties and methods. You can, of course implement many interfaces but those interfaces cannot have implementations (Yes, in Java 8 there are now default methods for interfaces, but they can't contain any properties for those methods to operate on). The result is a ton of boiler plate code where Java objects implement interfaces but need to hardcode the link of that interface fulfillment to some implementation that is shared across many objects. This boiler plate code sometimes boils my blood! OK, I'm not that mad at it but it sounded good. I do think that this inability to multiply inherit content from two base classes has resulted in far more code than truly needed, and to me code is a liability.

The issue comes down to lack of language features. The disdain for the diamond of death inheritance structure is largely due to tricky/dangerous language semantics of C++, but when we are operating in a language that handles it more safely many of the reasons for avoiding it disappear. MATLAB for example handles multiple inheritance in a much more rational and understandable way. Encountering a diamond structure is not as severe as doing so in C++ and sometimes may even be perfectly fine. For example, there only exists a single instance of the common base class (A above) and method ambiguities are caught and prevented.

Ultimately, I often find when having engaging discussions about this problem that many view multiple inheritance as a smell and avoid the diamond structure at all costs. However, when we start getting into why they do so it is hard to find an answer that is independent from specifics of a particular language like C++.

I am not advocating rushing out and adding a bunch of diamond structures to your code! Indeed it often does signal a possible abstraction problem and there are subtleties (e.g. there is only one instance of the shared base class, but MATLAB invokes its constructor twice). However, in MATLAB it is much more manageable, and ultimately getting comfortable with the diamond problem opens you up to the use of mixins. The use of mixins is a powerful design tactic that leverages multiple inheritance and is an alternative to composition that similarly helps keep hierarchies wide. Let's get into those next time.

What do you think? Am I missing anything here? Can you help describe fundamental problems with the diamond problem that transcend language semantics? Have you ever encountered the diamond in MATLAB deliberately or accidentally, and if so what affect did it have?

Get the MATLAB code

Published with MATLAB® R2015a

2 CommentsOldest to Newest

kevin replied on : 1 of 2
"The result is a ton of boiler plate code where Java objects implement interfaces but need to hardcode the link of that interface fulfillment to some implementation that is shared across many objects." Reminds me of this: Either you have duplicated code or... Delegates. Delegates everywhere... It sort of makes me wonder: if I have to pass in a reference to an object in order to satisfy an interface, in what sense am I really "implementing" the interface?
Andy Campbell replied on : 2 of 2
Thanks Kevin. I also saw Uncle Bob's post in January and thought to myself, "Great, I have some backup on this!" Actually I meant to include a reference to it from this post so thank you for sharing it. For too long I've heard nothing but almost dogmatic resistance to multiple inheritance and it all seems to point to the diamond as a cause. Lest I go too far I do still think that composition-over-inheritance is a sound principle. I am not negating my previous blog post at all. Its just that I think there are cases where actually inheriting interface and implementation from multiple classes is the right design move, and I don't like it when a language doesn't give me that tool. That's a good point about what it really means to implement an interface. I've always thought an alternative to Java's approach would have been to just make the delegation easier and a fundamental feature of the language to avoid boiler plate. Private inheritance almost gets there in C++. There you can privately inherit the functionality without inheriting the interface and substitutability. The only missing link is from there delegating to the inherited methods without boiler plate. Generally I think that languages these days solve these problems with mixins/traits. We seem to have turned a corner with respect to fear of the diamond.