Почему я должен избегать множественного наследования в C++?

с интервью с Бьярне Страуструп:

люди совершенно правильно говорят, что вам не нужно множественное наследование, потому что все, что вы можете сделать с множественным наследованием, вы также можете сделать с одним наследованием. Вы просто используете трюк делегирования, о котором я упоминал. Кроме того, вам вообще не нужно наследование, потому что все, что вы делаете с одним наследованием, вы также можете сделать без наследования, переадресовав через класс. На самом деле, вам не нужно любые занятия, потому что вы можете делать все это с указателями и структурами данных. Но зачем тебе это делать? Когда удобно пользоваться языковыми средствами? Когда бы вы предпочли обходной путь? Я видел случаи, когда множественное наследование полезно, и я даже видел случаи, когда довольно сложное множественное наследование полезно. Как правило, я предпочитаю использовать возможности, предлагаемые языком, чтобы делать обходные пути

нет никаких причин, чтобы ее избежать, и это может быть очень полезно в ситуациях. Вы должны быть в курсе потенциальных проблем, хотя.

самый большой из них-Алмаз смерти:

class GrandParent;
class Parent1 : public GrandParent;
class Parent2 : public GrandParent;
class Child : public Parent1, public Parent2;

теперь у вас есть две "копии" бабушки и дедушки внутри ребенка.

C++ подумал об этом, хотя и позволяет делать виртуальное наследование, чтобы обойти проблемы.

class GrandParent;
class Parent1 : public virtual GrandParent;
class Parent2 : public virtual GrandParent;
class Child : public Parent1, public Parent2;

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

см. w:Множественное Наследование.

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

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

множественное наследование в языке с Конструкторы стиля C++ / Java усугубляет проблему наследования конструкторы и цепочка конструкторов, таким образом создавая обслуживание и проблемы расширяемости в этих языки. Объекты в порядке наследования отношения с сильно варьирующимися методы строительства трудно реализовать под конструктором цепная парадигма.

современный способ решения этой проблемы использовать интерфейс (чистый абстрактный класс), как интерфейс COM и Java.

Я могу делать другие вещи, вместо этого?

да, можно. Я собираюсь украсть у г.

• программа для интерфейса, а не реализация
• предпочитайте композицию наследованию

публичное наследование-это отношение IS-a, и иногда класс будет типом нескольких разных классов,и иногда это важно отразить.

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

пока иерархия наследования довольно мелкая (как это должно быть почти всегда) и хорошо управляется, вы вряд ли получите страшный Алмаз наследование. Алмаз не является проблемой для всех языков, которые используют множественное наследование, но обработка C++часто неудобна и иногда озадачивает.

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

вы не должны "избегать" множественного наследования, но вы должны знать о проблемах, которые могут возникнуть, таких как "алмазная проблема" ( http://en.wikipedia.org/wiki/Diamond_problem) и относитесь к данной вам силе с осторожностью, как вы должны относиться ко всем силам.

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

alt текст http://www.learncpp.com/images/CppTutorial/Section11/PoweredDevice.gif

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

другие люди обращались к вопросу о том, что множественное наследование не хорошо. Но мы видели довольно много комментариев, которые более или менее подразумевают, что причина избежать этого заключается в том, что это небезопасно. Ну и да, и нет.

Как это часто бывает в C++, если вы следуете базовому руководству, вы можете использовать его безопасно, без необходимости постоянно "оглядываться через плечо". Ключевая идея заключается в том, что вы различаете особый вид определения класса, называемый "mix-in"; класс является mix-in, если все его функции-члены являются виртуальными (или чисто виртуальными). Тогда вам разрешено наследовать от одного основной класс и столько "mix-ins", как вам нравится - но вы должны наследовать mixins с ключевым словом"virtual". например,

class CounterMixin {
    int count;
public:
    CounterMixin() : count( 0 ) {}
    virtual ~CounterMixin() {}
    virtual void increment() { count += 1; }
    virtual int getCount() { return count; }
};

class Foo : public Bar, virtual public CounterMixin { ..... };

мое предложение заключается в том, что если вы собираетесь использовать класс в качестве смешанного класса, вы также принимаете Соглашение об именах, чтобы облегчить любому, кто читает код, чтобы увидеть, что происходит, и проверить, что вы играете по правилам основного руководства. И вы обнаружите, что он работает намного лучше, если ваши миксы также имеют конструкторы по умолчанию, просто из-за того, как виртуальная база занятия работают. И не забудьте сделать все деструкторы виртуальными тоже.

обратите внимание, что мое использование слова "mix-in" здесь не совпадает с параметризованным классом шаблона (см. этой ссылке для хорошего объяснения), но я думаю, что это справедливое использование терминологии.

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

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

если мы подумаем обо всех наших классах и стрелках между ними, обозначающих отношения наследования, то что-то вроде этого

A --> B

означает, что class B происходит от class A. Обратите внимание, что, учитывая

A --> B, B --> C

мы говорим с производным от B, который наследуется от A, так тоже говорят, происходит от, таким образом

A --> C

кроме того, мы говорим, что для каждого класса A что тривиально A происходит от A, таким образом, наша модель наследования выполняет определение категории. В более традиционном языке, у нас есть категория Class С объектами всех классов и морфизмов отношения наследования.

это немного настройки, но с этим давайте взглянем на наш Алмаз судьбы:

C --> D
^     ^
|     |
A --> B

это тенистый вид диаграммы, но это будет делать. Так D наследует от всех A,B и C. Кроме того, и приближаясь к решению вопроса OP,D также наследует от любого суперкласса A. Мы можем нарисовать диаграмму

C --> D --> R
^     ^
|     |
A --> B
^ 
|
Q

теперь, проблемы, связанные с Алмазом смерти здесь, когда C и B поделитесь некоторыми именами свойств / методов, и все становится неоднозначным; однако, если мы переместим любое общее поведение в A затем двусмысленность исчезнет.

положить в категорические термины, мы хотим A,B и C быть таким, что если B и C наследовать от Q затем A может быть переписан как подкласс Q. Это делает A что-то под названием pushout.

существует также симметричная конструкция на D называют откат. Это по существу самый общий полезный класс, который вы можете построить, который наследует от обоих B и C. То есть, если вы есть любой другой класс R умножить унаследованный от B и C, потом D - это класс, где R может быть переписан как подкласс D.

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

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

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

TL; DR считайте, что отношения наследования в вашей программе образуют категорию. Тогда вы можете избежать проблем с Алмазом Doom, сделав многократно унаследованные классы pushouts и симметрично, делая общий родительский класс, который является откатом.

мы используем Eiffel. У нас отличный Ми. Не волнуйся. Никакой вопрос. Легко управлять. Есть время, чтобы не использовать MI. Тем не менее, это полезно больше, чем люди понимают, потому что они: а) на опасном языке, который не справляется с этим хорошо-или - Б) удовлетворены тем, как они работали вокруг ми в течение многих лет и лет-или - в) другие причины (слишком много, чтобы перечислить я совершенно уверен-см. ответы выше).

для нас, используя Eiffel, MI так же естественно, как и все остальное, и еще один прекрасный инструмент в наборе инструментов. Честно говоря, нас совершенно не волнует, что никто больше не использует Eiffel. Не волнуйся. Мы довольны тем, что у нас есть, и приглашаем вас посмотреть.

пока вы смотрите: обратите особое внимание на Void-безопасность и искоренение разыменования нулевого указателя. Пока мы все танцуем вокруг Ми, ваши указатели теряются! : -)

использование и злоупотребление наследования.

статья делает большую работу по объяснению наследования, и это опасности.

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

композиция по своей сути легко понять, понять и объяснить. Это может стать утомительным для написания кода, но хорошая IDE (прошло несколько лет с тех пор, как я работал с Visual Studio, но, конечно же, у всех IDE Java есть отличные инструменты автоматизации быстрого доступа к композиции) должна помочь вам преодолеть это препятствие.

также, в плане обслуживания, "проблема бриллианта" приходит в буквальном случаях наследования, а также. Например, если у вас есть A и B, и ваш класс C расширяет их оба, а у A есть метод "makeJuice", который делает апельсиновый сок, и вы расширяете его, чтобы сделать апельсиновый сок с завихрением Лайма: что происходит, когда дизайнер для " B "добавляет метод "makeJuice", который генерирует и электрический ток? 'A' и ' B 'могут быть совместимыми "родителями"прямо сейчас, но это не значит, что они будут всегда так будет!

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

для C++ в частности, ключевая слабость функции это не фактическое существование множественного наследования, но некоторые конструкции, которые он позволяет, почти всегда искажены. Например, наследование нескольких копий одного и того же объекта, например:

class B : public A, public A {};

является уродливым по определению. В переводе на английский это "B-это A и A". Таким образом, даже в человеческом языке есть серьезная двусмысленность. Вы имели в виду "Б-2" или просто "Б-а"?. Позволяя такой патологический код, и что еще хуже, делая его примером использования, C++ не помогал, когда дело доходило до создание аргумента для сохранения функции на последующих языках.

вы можете использовать композицию вместо наследования.

общее ощущение, что композиция лучше, и это очень хорошо обсуждается.

это занимает 4/8 байт на класс участвует. (Один этот указатель на класс).

Это может не быть проблемой, но если у вас есть микро-структуры данных, которые приведены в миллиарды раз будет.