Какие есть хорошие альтернативы множественному наследованию в .NET?

Один из подходов - использовать методы расширения с интерфейсом для обеспечения реализации вашего «производного класса», как и 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"; } }
}

Использование: если у вас есть директива using для (или находится в том же пространстве имен, что и) пространство имен, в котором определены ваши методы расширения:

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

Здесь у вас есть два варианта; использовать интерфейсы или использовать композицию. Честно говоря, интерфейсы очень мощные, и после прочтения этой строчки

Интерфейсное решение для меня не имеет никакого смысла. (Честно говоря, интерфейсы никогда не имели для меня особого смысла ...)

Я считаю, что вам следует научиться правильно ими пользоваться. Тем не менее, если есть просто какая-то логика, которая нужна нескольким классам, но для этих классов нет смысла наследовать от одного и того же базового класса, просто создайте класс для инкапсуляции этой логики и добавьте переменную-член этого класса в свои классы. которые создают вам проблемы. Таким образом, все классы содержат логику, но могут быть разделены в своих иерархиях наследования. Если классы должны реализовывать общий интерфейс (ы), используйте интерфейсы.

Я смотрю на это, а CustomizableObject просто кричит, чтобы его превратили в интерфейс (и поскольку каждый конкретный тип может быть преобразован в объект, эта часть имени избыточна). Проблема, с которой вы столкнулись, заключается в том, что вы не знаете, как сохранить некоторую базовую логику, которая будет совместно использоваться или лишь незначительно отличаться в зависимости от реализации, и вы хотите сохранить эту логику в самом дереве, чтобы она работала полиморфно (это что за слово?).

Вы можете добиться этого через делегатов. Я не уверен, какие именно участники доставляют вам проблемы, но, возможно, что-то вроде этого:

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

Кроме того, у вас, вероятно, есть некоторая действительно статичная логика, которая, по вашему мнению, действительно принадлежит к вашему типу CustomizableObject. Но это, вероятно, неверно: вы создали тип с намерением использовать этот тип в конкретной ситуации. Например, из контекста кажется, что вы создадите эти элементы управления и анимацию и будете использовать их в Windows Form. Необходимо создать собственную форму, наследуемую от базового System.Windows.Form, и этот новый тип формы должен знать об ICustomizableObject и о том, как его использовать. Вот куда пойдет ваша статическая логика.

Это кажется немного неудобным, но это доказывает свою точность, когда вы решаете изменить движок представления. Что произойдет, если вы перенесете этот код в WPF или Silverlight? Им, вероятно, потребуется использовать ваш код реализации немного иначе, чем в Windows Forms, и вам все равно, вероятно, придется изменить свои реализации CustomizableControl. Но ваша статическая логика теперь находится точно в нужном месте.

Наконец, мне кажется, что используемый вами метод LoadObject () тоже находится не в том месте. Вы говорите, что хотите, чтобы каждый настраиваемый тип предоставлял метод, который вы можете вызвать, который знает, как загружать / создавать себя. Но это совсем другое дело. Возможно, вам понадобится еще один интерфейс с именем IConstructable<T>, и ваш тип ICustomizable реализует это (IConstructable<ICustomizable>).

В таком случае я использую миксины. примеси - это мощная концепция, используемая во многих языках для добавления функциональности классу во время выполнения. миксины хорошо известны на многих языках. Фреймворк повторного микширования - это фреймворк, который привносит технологию микширования в .NET.

Идея проста: украсьте свой класс атрибутом класса, представляющим миксин. Во время выполнения эта функция будет добавлена ​​к вашему классу. Таким образом, вы можете имитировать множественное наследование.

Решением вашей проблемы может быть превращение CustomizableObject в миксин. Для этого вам понадобится фреймворк повторного микширования.

[Использует (CustomizableObjectMixin)] CustomizableControl: UserControl

Пожалуйста, посетите remix.codeplex.com для получения более подробной информации.

Похоже, придется прибегнуть к интерфейсам и композиции объектов.

Я думаю, это одно из решений.

public interface IClassA
{
    void Foo1();
    void Foo2();
}

public interface IClassB
{
    void Foo3();
    void Foo4();
}

public class ClassA :IClassA
{
    #region IClassA Members

    public void Foo1()
    {
    }

    public void Foo2()
    {
    }

    #endregion
}

public class ClassB :IClassB
{
    #region IClassB Members

    public void Foo3()
    {
    }

    public void Foo4()
    {
    }

    #endregion
}

public class MultipleInheritance :IClassA, IClassB
{
    private IClassA _classA;
    private IClassB _classB;

    public MultipleInheritance(IClassA classA, IClassB classB)
    {
        _classA = classA;
        _classB = classB;
    }

    public void Foo1()
    {
        _classA.Foo1();
    }

    public void Foo2()
    {
        _classA.Foo2();
        AddedBehavior1();
    }

    public void Foo3()
    {
        _classB.Foo3();
        AddedBehavior2();
    }

    public void Foo4()
    {
        _classB.Foo4();
    }

    private void AddedBehavior1()
    {

    }

    private void AddedBehavior2()
    {

    }
}

Класс MultipleInheritance добавляет новое поведение к двум разным объектам, не влияя на поведение этих объектов. MultipleInheritance имеет то же поведение, что и доставленные объекты (наследует оба поведения).