Большие абстрактные базовые классы

Question

Я пишу большой абстрактный базовый класс с 30 чем-то чисто виртуальными методами *.

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

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

_{* То, что он делает, это обеспечивает уровень общей функциональности между несколькими различными подсистемами рендеринга.}

Answer 1

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

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

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

Answer 2

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

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

Когда вы создаете абстрактный базовый класс, количество чисто виртуальных методов не важно (для меня), но это должно быть яснопочему каждый класс, производный от этого интерфейса, должен реализовывать каждую чисто виртуальную функцию.Если вы подумаете: «Почему я должен реализовывать эту функцию?», Может быть целесообразно разбить абстрактный класс на несколько отдельных интерфейсов.

Answer 3

Обычно, сразу после ошибки «Не удается создать экземпляр абстрактного класса» (которая выдается в строке, в которой он был вызван), если вы скопировали и вставили интерфейс в класс перед написанием реализаций, вы получите ошибку компоновщика »Неразрешенная внешняя ошибка ", указывающая на метод, который вы забыли реализовать.

Answer 4

В любом случае, такой большой класс - беспорядок, класс Бога антипатерн. Используйте агрегацию / композицию, чтобы разделить класс и взглянуть на принципы разработки SOLID, похоже, что 30 методов для одного класса не следуют принципу единой ответственности, по крайней мере ... поэтому я хотел бы рекомендовать пересмотреть дизайн класса. Удачи!