Affaire pour hériter d'une classe non triviale?

Question

Je lisais le mot clé scellé en C #. Je ne me souviens plus de la dernière fois que j'ai hérité d'une bibliothèque standard. En c ++, je me souviens d'avoir hérité d'une interface std qui typé quelques types et utilisé certains de mes paramètres. Mais c’est 1) Trivial 2) Une interface

De mémoire, je ne me souviens pas de la classe dont j’ai hérité qui n’a pas de fonction virtuelle qui s’attend à être héritée. Quelqu'un peut-il me parler d'une situation dans laquelle vous deviez hériter d'une classe non triviale qui n'était pas une interface?

Je pourrais même dire que c’est une bonne règle de ne pas hériter d’une classe si elle n’a pas de fonctions virtuelles. Est-ce une bonne règle?

REMARQUE: j'utilise l'opérateur SomeClass & amp; SomeClass () {return m_someClass; } dans le cas où j'ai besoin de passer mon objet comme une autre classe. Cela fonctionne bien.

Answer 1

En réalité, il est utilisé en C ++ pour tous ces types d’héritage (par exemple, hériter d’une implémentation, mixins, boost :: noncopyable, où vous en héritez et rendez votre classe non-copable, boost :: operators où vous héritez d’une classe et que cela ajoutera des opérateurs à votre classe). En outre, lors de la métaprogrammation avec des types C ++, hériter d’un ou plusieurs autres types est l’une des méthodes les plus simples de composition de types.

Un autre cas dans lequel vous héritez d'une classe qui n'a pas de fonctions virtuelles, mais sert de "type de" une interface est un polymorphisme statique (techniques telles que CRTP, où la classe ConcreteA: BaseA). Ils n’ont pas besoin des fonctions virtuelles, car tout est résolu au moment de la compilation.

Toutefois, si vous souhaitez traiter votre classe avec une exécution polymorphe, vous devez réellement créer au moins une méthode virtuelle, qui serait le destructeur. Il existe des exceptions, mais rares.

Même lorsque vous avez une hiérarchie polymorphe, vous dérivez parfois de classes concrètes. Un exemple serait un SingleLineEdit dérivé de TextEdit. Cependant, ceci est un peu dangereux, car il casse l’encapsulation de la classe parente (par exemple, ses méthodes peuvent s’attendre à des détails d’implémentation, et vous devez les respecter et les conserver dans la sous-classe - ce qui peut être délicat, car ce sont des détails d'implémentation qui peuvent changer sans préavis dans la prochaine version, etc.)

Answer 2

Je dirais que le concept clé de la programmation orientée objet est le polymorphisme. Si hériter d'une classe particulière ne vous permet pas de tirer parti du polymorphisme, alors à quoi sert-il d'hériter? Donc, s'il n'y a pas de méthodes à remplacer, ne sous-classe pas. Vous ne feriez qu'accroître la complexité de votre code. Si vous souhaitez utiliser la même fonctionnalité, enveloppez la classe existante dans la vôtre.