Использование для множественного наследования?

Question

Может ли кто-нибудь придумать, в какой ситуации можно использовать множественное наследование? Каждый случай, который я могу придумать, может быть решен оператором метода

AnotherClass() { return this->something.anotherClass; }

Answer 1

Я должен был использовать это сегодня, на самом деле ...

Здесь была моя ситуация - у меня была модель домена, представленная в памяти, где A содержал ноль или более B (представленных в массиве), у каждого B есть ноль или более C и C до D. Я не мог изменить тот факт, что они были массивами (источником этих массивов был автоматически сгенерированный код из процесса сборки). Каждый экземпляр должен был отслеживать, к какому индексу в родительском массиве они принадлежат. Им также нужно было отслеживать экземпляр своего родителя (слишком много подробностей относительно того, почему). Я написал что-то вроде этого (было что-то еще, и это не синтаксически правильно, это просто пример):

class Parent
{
    add(Child c)
    {
        children.add(c);
        c.index = children.Count-1;
        c.parent = this;
    }
    Collection<Child> children
}

class Child
{
    Parent p;
    int index;
}

Затем для типов доменов я сделал это:

class A : Parent
class B : Parent, Child
class C : Parent, Child
class D : Child

Фактически реализация была в C # с интерфейсами и обобщениями, и я не мог сделать множественное наследование, как если бы язык поддерживал его (нужно было сделать некоторую вставку копии). Итак, я решил поискать ТАК, чтобы узнать, что люди думают о множественном наследовании, и я получил ваш вопрос;)

Я не мог использовать ваше решение .anotherClass из-за реализации add для Parent (ссылается на это - и я хотел, чтобы это не был какой-то другой класс).

Это стало еще хуже, потому что сгенерированный код имел подкласс A, который не был ни родителем, ни потомком ... подробнее copy paste.

Answer 2

Следующий пример чаще всего встречается в C ++: иногда это может быть необходимо из-за нужных вам служебных классов, но из-за того, что их дизайн не может быть использован посредством компоновки (по крайней мере, неэффективно или без того, чтобы сделать код еще более запутанным, чем возвращаясь к мульт. наследованию). Хороший пример - у вас есть абстрактный базовый класс A и производный класс B, и B также должен быть своего рода сериализуемым классом, поэтому он должен происходить, скажем, от другого абстрактного класса, называемого Serializable. Можно избежать MI, но если Serializable содержит только несколько виртуальных методов и нуждается в глубоком доступе к закрытым членам B, то, возможно, стоило бы запятнать дерево наследования, просто чтобы избежать объявления друзей и предоставления доступа к внутренним компонентам B некоторым класс вспомогательной композиции.