Comments on: The Diamond of Breadth https://blogs.mathworks.com/developer/2015/06/08/diamond-of-death/?s_tid=feedtopost Developing, testing, and integrating production grade software using MATLAB. Fri, 09 Sep 2016 02:13:48 +0000 hourly 1 https://wordpress.org/?v=6.2.2 By: Andy Campbell https://blogs.mathworks.com/developer/2015/06/08/diamond-of-death/#comment-1045 Fri, 12 Jun 2015 00:53:56 +0000 https://blogs.mathworks.com/developer/?p=173#comment-1045 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.

]]>
By: kevin https://blogs.mathworks.com/developer/2015/06/08/diamond-of-death/#comment-1044 Fri, 12 Jun 2015 00:06:40 +0000 https://blogs.mathworks.com/developer/?p=173#comment-1044 “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: http://blog.cleancoder.com/uncle-bob/2015/01/08/InterfaceConsideredHarmful.html
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?

]]>