Случай для наследования нетривиального класса?

Question

Я читал о запечатанном ключевом слове в C#. Я не могу вспомнить последний раз, когда я наследую стандартную библиотеку. В C++ я помню, наследуя интерфейс std, который typedef несколько типов и использовал некоторые из моих параметров. Но это 1) Тривиальный 2) Интерфейс

Сверху моей головы я не помню какой-либо класс, который унаследовал, у которого не было виртуальной функции, ожидающей наследования. Может ли кто-нибудь рассказать мне о ситуации, когда вам нужно было наследовать нетривиальный класс, который не был интерфейсом?

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

ПРИМЕЧАНИЕ: Я использую оператор SomeClass & SomeClass() {return m_someClass; } в случае, когда мне нужно передать мой объект в качестве другого класса. Это работает хорошо.

Answer 1

Фактически он используется в C++ для всех этих не-видов наследования (например, наследование реализации, mixins, boost :: noncopyable, где вы наследуете его и делаете свой класс не подлежащим копированию, boost :: операторы, в которых вы наследуете некоторый класс, и добавит некоторые операторы вашему классу). Кроме того, при метапрограммировании с типами C++ наследование от другого типа (ов) является одним из простейших методов составления типов.

Другой случай, когда вы наследуете класс, не имеющий виртуальных функций, но являющийся «видом» интерфейса, является статическим полиморфизмом (такие методы, как CRTP, где класс ConcreteA: BaseA). Им не нужны виртуальные функции, потому что все разрешено во время компиляции.

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

Даже если у вас есть полиморфная иерархия, вы иногда извлекаете из конкретных классов. Одним из примеров может быть SingleLineEdit, полученный из TextEdit. Тем не менее, это немного опасно, потому что он прерывает инкапсуляцию родительского класса (например, его методы могут ожидать некоторые детали реализации, и вы должны уважать и сохранять их в подклассе, что может быть сложно, поскольку они являются деталями реализации, которые могут изменение без уведомления в следующей версии и т. д.)

Answer 2

Я бы сказал, что ключевым понятием объектно-ориентированного программирования является полиморфизм. Если наследование из определенного класса не позволяет вам использовать полиморфизм, тогда в чем смысл наследования? Поэтому, если нет методов для переопределения, тогда не подклассы. Вы только увеличиваете сложность своего кода. Если вы хотите использовать ту же функциональность, просто оберните существующий класс самостоятельно.