Разработка классов с виртуальными методами

Question

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

Базовый интерфейс для всего

class IWindow 
    { 
    public: 
     virtual void Refresh() = 0; 
// another 100 virtual methods 
// ... 
    }; 

Этот интерфейс используется внутри библиотеки, которая не имеет ни малейшего представления о конкретной реализации.

Вот версия конкретной реализации

class ConcreteWindow : public IWindow 
    { 
    public: 
     void Refresh() override {} 
/// the other 100 overridden methods 
    }; 

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

class IDBDetail : public IWindow 
{ 
public: 
    virtual void DoDetail() = 0; 

}; 

и вот главная проблема, когда мы создаем конкретную inmplementation для него

class IGDBDetailWrapper : public IDBDetail, public ConcreteWindow 
{ 
public : 
    void DoDetail() {} 
}; 

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

Я могу скопировать/вставить эти 100 методов из ConcreteWindow в IGDBDetailWrapper, но это перебор, потому что у меня могут быть еще 10 таких новых интерфейсов и конкретных реализаций.

Какой еще шаблон можно использовать здесь, чтобы помочь решить вопрос, а не повторять эти 100 методов снова и снова?

Thx

Answer 1

Вы можете использовать виртуальное наследование. Если мы будем игнорировать этот факт должен IDBDetail наследовать от IWindow или нет, мы могли бы использовать виртуальное наследование для решения проблемы с текущей архитектуры:

class IWindow 
    { 
    public: 
     virtual void Refresh() = 0; 
// another 100 virtual methods 
// ... 
    }; 

    class ConcreteWindow : virtual public IWindow 
    { 
    public: 
     void Refresh() override {} 
/// the other 100 overridden methods 
    }; 

class IDBDetail : virtual public IWindow 
{ 
public: 
    virtual void DoDetail() = 0; 

}; 

class IGDBDetailWrapper : public IDBDetail, public ConcreteWindow 
{ 
public : 
    void DoDetail() {} 
}; 

Теперь компилятор будет использовать реализацию для 101 абстрактного метода из ConcreteWindow

Answer 2

Ваша конструкция работает в diamond problem.

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

class IDBDetail : public IWindow { 
    public: 
    virtual void DoDetail() = 0; 

}; 

Из описания вашего интерфейса IDBDetail выглядит IDBDetail не должны наследовать от IWindow. Если его просто добавить дополнительные функции, то IDBDetail не обязательно должен быть IWindow. Это просто нужно понять IWindow. Например, чтобы обезьяна делала что-то особенное, тренер не должен быть обезьяной.

Decorator pattern может быть тем, что вы ищете.

Answer 3

Вы должны переопределить все методы абстрактного класса, другого пути нет. На самом деле вы не должны создавать абстрактный класс из 100 методов здесь и все. Возможно, вы можете разделить его на несколько более мелких абстрактных классов? Однако в этом случае IDBDetail не должен наследовать после того, как IWindow и IGBDDetailWrapper также не должны наследовать после IWindow - и мы здесь.

Answer 4

Во-первых, если вы используете Visual Studio есть инструменты рефакторинга, которые могут помочь вам с этим автоматизации, что может быть иначе утомительной задачей, второй:

мне много бессмысленно делать то же самое:

class IDBDetail : public IWindow 
{ 
public: 
    virtual void DoDetail() = 0; 

}; 

Я хотел бы сделать что вместо

class IDBDetail 
{ 
public: 
    virtual void DoDetail() = 0; 

}; 

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

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

class IDBDetailWithConcreteWindow: public IDBDetail{ 

    IWindow * concreteWindow; 
public: 
    IDBDetailWithConcreteWindow(IWindow * window){ 
     concreteWindow = window; 
    } 

    void Refresh() override{ 
     concreteWindow->Refresh(); 
    } 
} 

И, наконец, в любой полученный класса вы только реализовать методы из IDBDetail

IGDBDetailWrapper: public IDBDetailWithConcreteWindow{ 
public: 

    void DoDetail() override { } 
} 

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

Answer 5

Это не решит проблему, но, по крайней мере, вы можете перенаправить исполнения ордеров себя:

class IGDBDetailWrapper : public IDBDetail, public ConcreteWindow 
{ 
public: 
    virtual void DoDetail() override { /*work here*/ } 

    virtual void Refresh() override { ConcreteWindow::Refresh(); } 
    //another 100 methods 
}; 

Вы можете сделать блок таких перенаправлений как компилятор #DEFINE и повторить столько раз, сколько вы хотите.

Answer 6

@bashrc является правильным, но это должно быть возможно решить проблему с виртуальным наследованием:

class ConcreteWindow : public virtual IWindow {...} 

class IDBDetail : public virtual IWindow {...} 

Эта статья в Википедии на virtual inheritance государства решение, как хорошо.