C ++: Избегать двойного обслуживания в иерархиях наследования - PullRequest
3 голосов
/ 01 марта 2010

При создании структуры наследования C ++ необходимо определить функции-члены в нескольких местах одинаково:

Если B является абстрактным базовым классом, а D, E и F все наследуются от B, у вас может быть это:

class B
{
   virtual func A( ... params ) = 0;
};

class D : public B
{
   func A( ... params );
};

/* ... etc... similar implementations for E and F */

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

Коллега предложил несколько хитростей со встроенным хитроумно созданным #include, ala:

class D: public B
{
   #include "B_Interface.h"  // B_Interface.h is a specially crafted .h file
}

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

Кроме того, может быть, решение здесь - действительно лучшие инструменты для поддержки языка, такие как Visual Assist X?

Редактировать: Предположим, что производные классы должны иметь уникальные реализации.

Ответы [ 5 ]

12 голосов
/ 02 марта 2010

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

4 голосов
/ 02 марта 2010

Кроме того, может быть, решение здесь - действительно лучшие инструменты для поддержки языка, такие как Visual Assist X?

Точно. Изменение сигнатур методов - это ключевая особенность инструментов рефакторинга.

4 голосов
/ 02 марта 2010

Что больно менять широко используемый интерфейс - это не ошибка;это особенность.

1 голос
/ 02 марта 2010

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

1 голос
/ 01 марта 2010

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

...