Comments on: C++ had it right, Multiple Inheritance Rocks, Single Inheritance… not so much. http://josephbulger.com/technology/c-had-it-right-multiple-inheritance-rocks-single-inheritance-not-so-much/ God, Family, Church, Engineering Wed, 09 Jun 2010 14:46:26 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: herzmeister_der_welten http://josephbulger.com/technology/c-had-it-right-multiple-inheritance-rocks-single-inheritance-not-so-much/comment-page-1/#comment-313 herzmeister_der_welten Tue, 13 Oct 2009 10:47:29 +0000 http://josephbulger.com/?p=60#comment-313 I heavily disagree that you would derive Coin from Currency. Obviously, that's a property. A coin is NOT a Currency, a Coin rather HAS a or IS OF a Currency. So a Coin x has a property Currency, and Currency class has all the complex economy code. Deriving coin from a MetalObject makes slightly more sense, but that is depending on the context of what you want to achieve, as it always is. When your application system has only economy and no metallurgy code, then there's no need for any MetalObject base class. Modern paradigms support Composition over Inheritance anyway. At last, you can resolve anything to a Has-A-Relationship, you would never need an Is-A-Relationship. Unfortunately, the latter is not supported very well by todays programming languages without writing tons of tedious wrapper methods resulting probably in bad performance too. I believe that concepts like MixIns and Traits are the future. I heavily disagree that you would derive Coin from Currency. Obviously, that’s a property. A coin is NOT a Currency, a Coin rather HAS a or IS OF a Currency. So a Coin x has a property Currency, and Currency class has all the complex economy code.

Deriving coin from a MetalObject makes slightly more sense, but that is depending on the context of what you want to achieve, as it always is. When your application system has only economy and no metallurgy code, then there’s no need for any MetalObject base class.

Modern paradigms support Composition over Inheritance anyway. At last, you can resolve anything to a Has-A-Relationship, you would never need an Is-A-Relationship.

Unfortunately, the latter is not supported very well by todays programming languages without writing tons of tedious wrapper methods resulting probably in bad performance too.

I believe that concepts like MixIns and Traits are the future.

]]>