What are some good alternatives to multiple-inheritance in .NET?

Question

I've run into a bit of a problem with my class hierarchy, in a WPF application. It's one of those issues where you have two inheritance trees merging together, and you can't find any logical way to make your inheritance work smoothly without multiple inheritance. I'm wondering if anyone has any bright ideas for getting this kind of system working, without making it impossible to follow or debug.

I'm a low-level engineer, so my first thought is always, "Oh! I'll just write some of these classes in native C++, and reference them externally! Then I can have all my old-school OO fun!" Alas, this doesn't help when you need to inherit from managed controls...

Allow me to show a snippet of my current projected class diagram:

 ____________________________________      _____________________________________
| CustomizableObject                 |    | System.Windows.Controls.UserControl |
|____________________________________|    |_____________________________________|
|   string XAMLHeader()              |                        ▲
|   string XAMLFooter()              |◄--┐                    |
|   CustomizableObject LoadObject()  |   \                    |
|   <Possible other implementations> |    \                   |
|____________________________________|     \                  |
         ▲                      ▲           \                 |
         |                      |            \                |
         |                      |             \               |
 _________________    ______________________   \    _____________________
| SpriteAnimation |  | SpriteAnimationFrame |  └---| CustomizableControl |
|_________________|  |______________________|      |_____________________|
                                                      ▲             ▲
                                                      |             |
                                                      |             |
                                                  ________    _____________
                                                 | Sprite |  | SpriteFrame |
                                                 |________|  |_____________|

The problem is pretty clear: the separation of the CustomizableObject and CustomizableControl object trees --- and the insertion of UserControl into one, but not both, of the trees.

It makes no practical sense to move the implementation of CustomizableObject into its derived classes, since the implementation doesn't vary by class. Furthermore, it would be really confusing to have it implemented multiple times. So I really don't want to make CustomizableObject an interface. The interface solution doesn't make any sense to me. (Interfaces have never really made much sense to me, to be honest...)

So I say again, anyone have any bright ideas? This one's a real pickle. I'd like to learn more about making interfaces work WITH my object tree, rather than against it. I'm making this simple sprite engine using WPF and C# as a solid exercise, more than anything. This is so easy to solve in C++ - but I need to figure out how to solve these problems in a managed environment, rather than throwing my hands in the air and running back to Win32 whenever the going gets tough.

Answer 1

Looks like you'll have to resort to interfaces and object composition.

Answer 2

You have two options here; use interfaces, or use composition. Honestly, interfaces are very powerful, and after reading this line

The interface solution doesn't make any sense to me. (Interfaces have never really made much sense to me, to be honest...)

I think that you should learn how to use them properly. That said, if there is simply some logic that multiple class need, but it does not make sense for these classes to inherit from the same base class, just create a class to encapsulate that logic and add a member variable of that class to your classes that are giving you problems. This way all of the classes contain the logic but can be separate in their inheritance hierarchies. If the classes should implement a common interface(s), then use interfaces.

Answer 3

One approach is to use extension methods with an interface to provide your "derived class" implementation, much like System.Linq.Queryable:

interface ICustomizableObject
{
    string SomeProperty { get; }
}

public static class CustomizableObject
{
    public static string GetXamlHeader(this ICustomizableObject obj)
    {
        return DoSomethingWith(obj.SomeProperty);
    }

    // etc
}

public class CustomizableControl : System.Windows.Controls.UserControl, ICustomizableObject
{
    public string SomeProperty { get { return "Whatever"; } }
}

Usage: As long as you have a using directive for (or are in the same namespace as) the namespace where your extension methods are defined:

var cc = new CustomizableControl();
var header = cc.GetXamlHeader();

Answer 4

I'm looking at this, and CustomizableObject is just screaming to be made into an interface (and since every concrete type is convertable to object, that part of the name is redundant). The problem you're running into is that you're not sure how to preserve some basic logic that will be shared or only vary slightly by implementation, and you want to store this logic in the tree itself so that it will work polymorphically (is that a word?).

You can achieve this through delegates. I'm not sure exactly which members are giving you trouble, but perhaps something more like this:

 ____________________________________      _____________________________________
| ICustomizable                      |    | System.Windows.Controls.UserControl |
|                                    |    |_____________________________________|
|   Func<string> XAMLHeader;         |                        ▲
|   Func<string> XAMLFooter          |◄--┐                    |
|   ICustomizableObject LoadObject() |   \                    |
|   <Possible other implementations> |    \                   |
|____________________________________|     \                  |
         ▲                      ▲           \                 |
         |                      |            \                |
         |                      |             \               |
 _________________    ______________________   \    _____________________
| SpriteAnimation |  | SpriteAnimationFrame |  └---| CustomizableControl |
|_________________|  |______________________|      |_____________________|
                                                      ▲             ▲
                                                      |             |
                                                      |             |
                                                  ________    _____________
                                                 | Sprite |  | SpriteFrame |
                                                 |________|  |_____________|

Additionally, you likely have some logic that is genuinely static that you feel really belongs with your CustomizableObject type. But this is probably false: you built the type with the intent of using that type in a specific situation. For example, from the context it looks like you'll create these controls and animations and use them on a Windows Form. The thing to do is have your own form that inherits from the base System.Windows.Form, and this new form type should know about ICustomizableObject and how to use it. That's where your static logic will go.

This seems a little awkward, but it's proven accurate when you decide to change presentation engines. What happens if you port this code to WPF or Silverlight? They'll likely need to use your implementation code a little differently than Windows Forms would, and you'll still likely need to change your CustomizableControl implementations. But your static logic is now all in exactly the right place.

Finally, the LoadObject() method you're using stands out to me as in the wrong place as well. You're saying you that you want every Customizable type to provide a method you can call that knows how to load/construct itself. But this is really something different. You might want yet another interface named IConstructable<T> and have your ICustomizable type implement that (IConstructable<ICustomizable>).