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

Answer 1

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 XAMLHeader;         |                        ▲
|   Func XAMLFooter          |◄--┐                    |
|   ICustomizabl LoadObject() |   \                    |
|    |    \                   |
|____________________________________|     \                  |
         ▲                      ▲           \                 |
         |                      |            \                |
         |                      |             \               |
 _________________    ______________________   \    _____________________
| 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 and have your ICustomizable type implement that (IConstructable).