//C#: a way to get around the lack of multiple implementation inheritance

C#: a way to get around the lack of multiple implementation inheritance

I run across this question from time to time: why is there no multiple inheritance in C# like there was in C++.  Personally, I’ve never needed it, but I do see a value to it, and there are some times when it would appear to be handy.

There is a workaround to this problem that is not difficult to do.  You get some of the same abilities as multiple inheritance, with a few structural advantages.  Before I describe the solution (below), let me frame the problem so that we are all using the same terms.

We have two concrete classes.  They are both derived from different base classes (not interfaces).  You want to give both of them a set of common methods and properties that meets a defined interface or base class (multiple inheritance).

Note: if you just want to inherit from an interface and implement the properties and methods directly in the class, you can do that now.  That does not require a workaround.  In other words, it is perfectly acceptable to do this:

   public class MyClass : System.Web.UI.Page , MyNewInterface
   { … }

So the problem only really arises if you have two or more BASE CLASSES that you want to put on that line… something you cannot do in C#.  I will treat one base class as “given” and one as “add-on”.  It really doesn’t matter, structurally, which one is which.  There is only one “given” class.  There can be as many “add-on” base classes as you want.

So, you use a simple composition pattern (that I cannot find the name for… if someone knows the name, please send it to me).

Step 1) you need an interface.  This defines a single getter property with a name derived from the base class name of the class you want to add on.

interface IAddOn
{
    // define a getter to return one “AddOnClass” object
    AddOnClass GetAddOn
    {   get;   }
}

Step 2) insure that your concrete object inherits from IAddOn

public class MyMultiConcrete : MyBaseClass, IAddOn
{ …. }

Step 3) Create a factory object that will return a class of type ‘AddOnClass’  (optional, but good practice). 

public class AddOnFactory
{
   public static AddOnClass NewAddOnObject()
   {   return new AddOnClass();   // factory method
    }

}

[edited] I want to add one comment here.  You don’t have to return a type ‘AddOnClass.’  In fact, if the add on class is an abstract class, you cannot.  You would need to derive a class from AddOnClass and then instantiate one of those types.  If you created this class specifically to be called from your new type, then you have a pair of classes that work together.  The derived add-on has access to the private and protected members of the add on type. 

In this case, you can pass in a reference to the calling class:

    public static AddOnClass NewAddOnObject(IAddOn Caller)
    {   return new ConcreteAddOnClass(Caller);   // factory method }

This gives the concrete add on the ability to directly manipulate the ‘container’ when you call a property or method on it, as shown below.  [end edit]

Step 4) Declare, in your concrete classes, a private property to hold the reference:
      private AddOnClass _AddOn;

Step 5) In the constructor for your concrete class, call your factory object to return an object of type AddOnClass.  Assign the reference to the private _AddOn property.

   public MyMultiConcrete() : base()
   {    // do normal constructor stuff here…
         _AddOn = AddOnFactory.NewAddOnObject();
   }

Step 6) Define the property that returns the add-on object
     public property AddOnClass GetAddOn
     {   Get { return _AddOn; } }

/// you are done ///

Now, every place in  your calling code, where someone needs a method or
property from the add-on type, they will reference it this way:
   MyMultiConcrete.GetAddOn.MyAddOnMethod()

One nice thing to consider, we can do this for as many types as we want within a class.  Therefore, we could theoretically inherit from dozens of base classes. 

I hope you have as much fun using this pattern as I have had describing it.  I doubt that I’m the first person to identify this pattern, so if someone can send me a link to another name or description, I will be grateful.  If not, perhaps I’ll go to ChiliPLoP and present it :-).

By |2004-12-31T14:03:00+00:00December 31st, 2004|Enterprise Architecture|10 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

10 Comments

  1. James Hancock December 31, 2004 at 8:48 pm - Reply

    The end result is the same as inheritence in VB6 work arounds. You still have to write a lot of code for nothing.

    Here’s what you’d use this for (just an example)

    Base Class A = TextBox

    Base Class B = ComboBox

    Base Class C = OurOwnClass

    Now you have:

    public TextBoxEx : TextBox, OurOwnClass {}

    and

    public ComboBoxEx : ComboBox, OurOwnClass{}

    Now if you want both the TextBoxEx and ComboBoxEx functions to share some methods and properites (i.e. themeaware etc.) you have to impliment them manually in both places the way you do above (hopefully)

    It gets worse if OurOwnClass inherits from it’s base class.

    I.e.

    public class OurOwnClass : Control {

    public override wndProc {

    //Do something interesting here like handle the theme change message.

    }

    }

    You don’t want to have (for code simplicity and maintainability) to override the wndProc in TextBoxEx and ComboBoxEx just to call OurOwnClass’s version of WndProc. that’s redundant. What you want to do is have one implimentation in OurOwnClass and have it automatically run correctly. Further, you want to be able to override wndProc in ComboBoxEx and call the Base version of WndProc and get everything you put into OurOwnClass and the stuff that you implimented that is specific to ComboBoxEx.

    This is the power of multiple inheritience, and since the .net framework supports it, there is no reason why it shouldn’t be included in C#. I really really wish this was in there, because there are a TON of cases where I would use this.

  2. Picho December 31, 2004 at 9:41 pm - Reply

    Hi Nick,

    Cant realy see the advantage here… this is a simple composition wrapped up in an interface. what happens to all the members defined as protected? how can I override and change the behaviour of the "derived" class? this solution merely givves me a way to combine the public interfaces of two calsses.

  3. Anna-Jayne Metcalfe January 1, 2005 at 1:46 am - Reply

    Maybe I’m missing something, but this just looks like a simple application of aggregation to me…

  4. Steven January 1, 2005 at 7:02 am - Reply

    You really haven’t done much more than create a composite aggregation (in the UML vernacular). This is a relationship in which object A "has an" object B and tends to expose or abstract B’s members as its own. The only slight difference, which is really semantic or at least less typing, is that you expose B rather than its members.

    But this pattern has an well known caveat that obviates its behavior as "inheritence".

    Being a member variable of MyMultiConcrete, _AddOn will have direct access to all members (private, protected and public) of MyMultiConcrete.

    But this is not transitive: MyMultiConcrete would only have access to the public members of _AddOn. There is no mechanism for "inheriting" even protected members.

  5. Wysiwyg January 3, 2005 at 8:29 am - Reply

    Thanks for the post!

    Is the term for the composition pattern you refer to a "contract"?

    Bill

  6. Wysiwyg January 3, 2005 at 9:37 am - Reply

    It looks like the interface property "GetAddOn" should actually be a property of "AddOn" in your example since it’s a property and that’s how you implemented it.

  7. Nick January 3, 2005 at 11:02 am - Reply

    As a seperate reply to James Hancock,

    Your example doesn’t quite follow my description. It appears that you are trying to demonstrate how you "wish" the framework would behave.

    The example I gave is quite different from VB6, in that you do have a contract between the caller and both the given class and the addon class. That contract is enforced with the IAddOn interface.

    As for the idea of "themeaware" being implemented in both places: the problem is taken care of in the constructor. If the constructor of the add-on class passes in a reference to the class that creates it, then the add-on member class is able to directly influence the behavior of the given class. If you add methods to the given class interface (IAddOn) to support this, then the addon can rely on the same interface for all of these manipulations, and is therefore abstracted from the fact that it is manipulating one or another type.

    Perhaps this is why multiple inheritance can be useful, but is rarely a necessity… because it can be worked around fairly readily.

  8. Nick January 3, 2005 at 11:15 am - Reply

    I edited the text somewhat to clarify how you can gain access to the private and protected members of the add-on class (see step 3). I also corrected a typo pointed out by wysiwyg.

  9. David M. Kean January 4, 2005 at 8:31 pm - Reply

    Trackback didn’t work, so posting this:

    I provided some feedback here:

    http://davidkean.net/archive/2005/01/02/216.aspx

  10. Pingback from  Workaround limitation of Multiple Inheritance Need | Q Lab

Leave A Comment

17 + 18 =