Дело о наследовании нетривиального класса?

Question

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

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

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

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

Answer 1

На самом деле он используется в C ++ для всех этих типов наследования not-is-a (например, наследование реализации, mixins, boost :: noncopyable, где вы наследуете ее и делаете свой класс некопируемым, boost :: operator где вы наследуете от некоторого класса, и это добавит несколько операторов в ваш класс). Кроме того, при выполнении метапрограммирования с типами C ++ наследование от другого типа (типов) является одним из самых простых методов составления типов.

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

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

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

Answer 2

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