Confused on C++ Multiple Inheritance

Question

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

Inheriting from both an interface and an implementation C++

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

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

Мои мои определения интерфейса выглядеть примерно так:

// Interface Definitions 
class IDigitalPoint 
{ 
public: 
    virtual void CommonDigitalMethod1() = 0; 
}; 

class IDigitalInputPoint : virtual IDigitalPoint 
{ 
public: 
    virtual void DigitialInputMethod1() = 0; 
}; 

class IDigitalOutputPoint : virtual IDigitalPoint 
{ 
public: 
    virtual void DigitialOutputMethod1() = 0; 
}; 

И мои реализации выглядеть следующим образом:

// Implementation of IDigitalPoint 
class DigitalPoint : virtual public IDigitalPoint 
{ 
public: 
    void CommonDigitalMethod1(); 
    void ExtraCommonDigitalMethod2(); 
} 

// Implementation of IDigitalInputPoint 
class DigitalInputPoint : public DigitalPoint, public IDigitalInputPoint 
{ 
public: 
    void DigitialInputMethod1(); 
    void ExtraDigitialInputMethod2(); 
} 

// Implementation of IDigitalOutputPoint 
class DigitalOutputPoint : public DigitalPoint, public IDigitalOutputPoint 
{ 
public: 
    void DigitialOutputMethod1(); 
    void ExtraDigitialOutputMethod2(); 
} 

Так как я мог бы переформатировать эту структуру, чтобы избежать ИМ?

Заранее благодарим за помощь.

Answer 1

«множественное наследование, как правило, является признаком плохого кода» - родители, которые являются чистыми интерфейсами, не учитываются в отношении этого правила.Ваши I* классы представляют собой чистые интерфейсы (содержат только чистые виртуальные функции), так что вы Digital*Point классы ОК в этом отношении

Answer 2

Это именно та ситуация, в которой стандартная библиотека делает виртуальным наследованием, в иерархии std::basic_iostream.

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

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

Например, Почему является точкой входа, отличной от точки вывода? A DigitalPoint звучит как вещь со свойствами, которые могут быть смоделированы классом. A DigitalInputPoint, однако, просто звучит как ... DigitalPoint как-то связано с источником входного сигнала. Имеет ли он разные свойства? Разное поведение? Что они и почему?

Answer 3

Вы можете перейти по ссылке ниже, чтобы понять больше о множественном наследовании Avoid Multiple Inheritance

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

Answer 4

Рассмотрим другой подход:

class DigitalPoint 
{ 
public: 
    void CommonDigitalMethod1(); 
    void ExtraCommonDigitalMethod2(); 
} 

// Implementation of IDigitalInputPoint 
class DigitalInputPoint 
{ 
public: 
    void CommonDigitalMethod1(); 
    void DigitialInputMethod1(); 
    void ExtraDigitialInputMethod2(); 
} 

// Implementation of IDigitalOutputPoint 
class DigitalOutputPoint 
{ 
public: 
    void CommonDigitalMethod1(); 
    void DigitialOutputMethod1(); 
    void ExtraDigitialOutputMethod2(); 
} 

Чтобы использовать так:

template <class T> 
void do_input_stuff(T &digitalInputPoint){ 
    digitalInputPoint.DigitialInputMethod1(); 
} 

Вы получаете более легкую реализацию с более четким дизайном и меньшим сцеплением с наиболее вероятной производительностью. Единственный Один недостаток заключается в том, что интерфейс неявно определяется использованием. Это можно смягчить, задокументировав то, что ожидает шаблон, и в конечном итоге вы сможете сделать это в концепциях, чтобы компилятор проверил его для вас.
Еще один недостаток в том, что у вас больше нет vector<IDigitalPoint*>.

Answer 5

Вы действительно уверены, что вам нужны 3 интерфейса?

class IDigitalPoint 
{ 
public: 
    virtual void CommonDigitalMethod1() = 0; 
}; 


enum class Direction : bool { Input, Output }; 

template <Direction direction> 
class DigitalPoint : public IDigitalPoint 
{ 
public: 
    void CommonDigitalMethod1() {} 
    void ExtraCommonDigitalMethod2() {} 

    virtual void DigitialMethod1() = 0; 
}; 

class DigitalInputPoint : public DigitalPoint<Direction::Input> 
{ 
public: 
    void DigitialInputMethod1() {} 
    void ExtraDigitialInputMethod2() {} 

    // This is like DigitialInputMethod1() 
    virtual void DigitialMethod1() override 
    {} 
}; 

class DigitalOutputPoint : public DigitalPoint<Direction::Output> 
{ 
public: 
    void DigitialOutputMethod1() {} 
    void ExtraDigitialOutputMethod2() {} 

    // This is like DigitialOutputMethod1() 
    virtual void DigitialMethod1() override 
    {} 
}; 

Answer 6

(множественное) наследование и интерфейсы имеют тенденцию к ненужным осложнениям простых отношений.

Здесь нам нужны только простая конструкция и несколько отдельно стоящих функций:

namespace example { 
    struct Point { T x; T y; } 

    Point read_method(); 
    void write_method(const Point&) 
    void common_method(Point&); 
    void extra_common_method(Point&); 
} // example 

common_method может быть кандидатом для функции члена Point. extra_common_method, который не так распространен, может быть кандидатом для другого класса, инкапсулирующего Point.

Answer 7

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

Если дочерние классы не используют функциональные возможности DigitalPoint, вы можете попробовать использовать CRTP. Это может сбить с толку, если вы не понимаете CRTP, но он работает как шарм, когда он подходит правильно. Live Example