Когда множественное наследование могло бы быть единственным разумным решением? [закрытый]

Существует ситуация, в которой вы должны унаследовать от класса и, возможно, реализовать один или два интерфейса в Java. Я думаю, это то, что вы могли бы решить с помощью множественного наследования в С ++.

C++ streams use multiple inheritance: istream and ostream are both parents of iostream. Since they both inherit from ios_base, you have a diamond.

It's the only "reasonable" solution in the sense that it would be unreasonable for the streams part of the standard libraries to take the same line as the algorithms and collections. So ostream behaves polymorphically rather than being a "duck-typed" interface like Iterator(*).

As soon as you have dynamic polymorphism, you need multiple inheritance to implement more than one interface at the same time.

(*) Presumably this is because anything else would be a shambles. You have to be able to write actual functions which manipulate streams, rather than forcing users to have templates everywhere. This is because it's common to write to "some stream, I don't know what until runtime", but not to want to manipulate "some collection, I don't know what until runtime".

As have been said on the other answers:

• Using pure virtual base classes as "Interfaces", as in Java ( http://en.wikipedia.org/wiki/Interface_(Java) ), this is a very common O.O. pattern in all O.O. languages, not only Java

• To do police-based design

But also:

• To compose a class with several mixins ( http://en.wikipedia.org/wiki/Mixin ); I consider this a very good use of multiple inheritance to achieve code reuse!

Если вы хотите унаследовать функциональность, а не роль, пример boost :: noncopyable (другие языки, которые поддерживают это (в отличие от Java и C #), называют это ] миксин ).

Multiple inheritance is useful if you need to inherit behavior, not just contract. However, as other languages demonstrate, multiple inheritance is not the only way to solve that problem, at the expense of making your inheritance tree deeper. As such, scenarios where you must and may only use multiple inheritance would be pretty rare.

I ' d почитайте об интерфейсах Java и т. д., чтобы лучше понять ответ на этот вопрос. Идея интерфейса заключается в создании абстрактного класса, который действует как шаблон для другого класса. Преимущество здесь в том, что шаблоны можно комбинировать в рамках конкретного класса. Например,

Родительский класс - FoodStore. Подкласс- CoffeeShop Подкласс - Bakery

С этим деревом наследования FoodStore может быть Bakery или CoffeeShop, но не обоими сразу. Но тогда что бы мы назвали Starbucks?

Лучше, IMO-

Parent Class- FoodStore Интерфейс - CoffeeShop Интерфейс - Bakery

открытый класс Starbucks расширяет FoodStore, реализует CoffeeShop, Bakery {...}

Вам нужно немного знать Java, чтобы понять это, но постарайтесь. Интерфейсы довольно элементарны, ИМО.

В качестве дальнейшего размышления, возможно, интерфейсы созданы так, чтобы подчиняться принципу «Не повторяйся». Очевидно, теперь, когда я упомянул об этом.

Когда вы должны объединить две или более сторонних иерархий классов, каждая из которых требует, чтобы объекты были производными от собственного базового класса иерархии, то отсутствие множественного наследования сделает ваш код сложным и неудобным.

namespace Object_Database {
    class Object {
      public:
        virtual void store() ;
        virtual void fetch() ;
    };
}

namespace Reflectives {
    class Object {
      public:
        virtual std::vector<std::string> > membernames();
        virtual std::vector<std::string> > methodnames();
    };
}

Первая иерархия позволяет пользователям создавать объекты, которые могут быть сериализованы в базу данных объектов и из нее, и требует, чтобы все такие объекты были производными от класса Object_Database :: Object. Вторая иерархия позволяет пользователям создавать объекты, которые могут быть запрошены во время выполнения для имен их членов, и требует, чтобы все такие объекты были производными от Reflectives :: Object.

Если вам требуются объекты, которые могут делать и то, и другое, вам просто нужно написать:

  class ReflectivePickle : 
  public Object_Database::Object, 
  public Reflectives::Object {
    // ...
  };

Другие решения неразумны.

Если вы хотите увидеть красивую реализацию множественного наследования, посмотрите Eiffel. Они решают проблему с бриллиантами путем переименования функций, намного проще, чем разрешение области видимости, и он даже поддерживает прямое повторное наследование, например:

A наследование B, B, B

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

Их библиотека ядра имеет открытый исходный код и несколько наследование широко используется, если вы хотите увидеть примеры.

http://sourceforge.net/projects/eiffelstudio/files/

Я обычно использую множественное наследование в C ++, когда базовые классы являются «интерфейсными классами», то есть базовыми классами, в которых все методы являются чисто виртуальными, ни у кого нет реализаций [помните, что вы все еще можете определить реализацию, но вы должны вызвать его явно], и нет членов данных. Очень похоже на «интерфейсы» в Java или (насколько я слышал) C #.

Чтобы использовать полиморфизм в C ++, вы не можете использовать композицию, вы должны использовать (публичное) наследование.

Итак, если класс Bar наследуется (публично) из Printable и Serializable я могу рассматривать объект как объект для печати, сериализуемый объект или объект Bar (используя указатели или ссылки).

С композицией вы не можете этого сделать.