Ромбовидное наследование (C++)

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

Обычно, если можно избежать первого, Вы более обеспечены с тех пор где-нибудь по линии, точный вызываемый метод может вызвать проблемы, и важность виртуальных оснований, состояний, и т.д., начинает иметь значение. На самом деле Java не позволил бы Вам вытягивать что-то как этот, он поддерживает только интерфейсную иерархию.

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

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

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

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

Я столкнулся с этой проблемой только на этой неделе и нашел статью о DDJ, который объяснил проблемы и когда Вы должны или не должны быть обеспокоены ими.Вот:

"Множественное наследование, Продуманное Полезный"

"Ромбы" в иерархии наследования интерфейсов довольно безопасны - это - наследование кода что get's Вы в горячую воду.

Для получения повторного использования кода я советую Вам рассматривать mixins (Google для C++ Mixins, если Вы незнакомы с tequnique). При использовании mixins Вы чувствуете, что можно "пойти по магазинам" для фрагментов кода, что необходимо реализовать Вас класс, не используя множественное наследование классов с сохранением информации.

Так, шаблон - множественное наследование интерфейсов и единственная цепочка mixins (предоставление Вам повторное использование кода), чтобы помочь реализовать реальный класс.

Hope, которая помогает!

С первым примером.....

, должен ли ActionRead ActionWrite быть подклассами действия вообще.

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

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

Со знанием больше того, что Вы делаете, я, вероятно, реорганизовал бы вещи немного. Вместо нескольких наследование со всеми этими версиями действия я сделал бы полиморфное чтение и запись и запись классов, instanciated как делегаты.

Что-то как следующее (который не имеет никакого ромбовидного наследования):

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

class Action // abstract
{
   // Reader and writer would be abstract classes (if not interfaces)
   // from which you would derive to implement the specific
   // read and write protocols.

   class Reader // abstract
   {
      Class Delay {...};
      Delay *optional_delay; // NULL when no delay
      Reader (bool with_delay)
      : optional_delay(with_delay ? new Delay() : NULL)
      {};
      ....
   };

   class Writer {... }; // abstract

   Reader  *reader; // may be NULL if not a reader
   Writer  *writer; // may be NULL if not a writer

   Action (Reader *_reader, Writer *_writer)
   : reader(_reader)
   , writer(_writer)
   {};

   void read()
   { if (reader) reader->read(); }
   void write()
   { if (writer)  writer->write(); }
};


Class Flow : public Action
{
   // Here you would likely have enhanced version
   // of read and write specific that implements Flow behaviour
   // That would be comment to FlowA and FlowB
   class Reader : public Action::Reader {...}
   class Writer : public Action::Writer {...}
   // for Reader and W
   Flow (Reader *_reader, Writer *_writer)
   : Action(_reader,_writer)
   , writer(_writer)
   {};
};

class FlowA :public Flow  // concrete
{
    class Reader : public Flow::Reader {...} // concrete
    // The full implementation for reading A flows
    // Apparently flow A has no write ability
    FlowA(bool with_delay)
    : Flow (new FlowA::Reader(with_delay),NULL) // NULL indicates is not a writer
    {};
};

class FlowB : public Flow // concrete
{
    class Reader : public Flow::Reader {...} // concrete
    // The full implementation for reading B flows
    // Apparently flow B has no write ability
    FlowB(bool with_delay)
    : Flow (new FlowB::Reader(with_delay),NULL) // NULL indicates is not a writer
    {};
};

Для случая 2, OneCommand не просто особый случай CompositeCommand? Если Вы устраняете OneCommand и позволяете CompositeCommand с только иметь один элемент, я думаю, что Ваш дизайн становится более простым:

              CommandAbstraction
                 /          \
                /            \
               /              \
        ModernCommand      CompositeCommand
               \               /
                \             /
                 \           /
             ModernCompositeCommand

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