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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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