¿Caso de heredar una clase no trivial?

Question

Estaba leyendo sobre la palabra clave sellada en C #. No puedo recordar la última vez que heredé de una biblioteca estándar. En c ++ recuerdo haber heredado una interfaz estándar que tipeaba algunos tipos y usaba algunos de mis parámetros. Pero eso es 1) Trivial 2) Una interfaz

Desde lo alto de mi cabeza, no recuerdo ninguna clase que heredé que no tuviera una función virtual que esperaba ser heredada. ¿Puede alguien decirme una situación en la que necesitó heredar una clase no trivial que no era una interfaz?

Incluso podría decir que es una buena regla recordar que no heredar una clase a menos que tenga funciones virtuales. ¿Es esta una buena regla de oro?

NOTA: uso el operador SomeClass & amp; SomeClass () {return m_someClass; } en el caso de que necesito pasar mi objeto como otra clase. Funciona bien.

Answer 1

En realidad se usa en C ++, para todos estos tipos de herencia no-es-un (por ejemplo, heredar una implementación, mixins, boost :: noncopyable, donde se hereda de ella y hace que su clase no sea copiable, boost :: operadores donde hereda de alguna clase y agregará algunos operadores a su clase). Además, cuando se realiza una metaprogramación con tipos C ++, la herencia de otro (s) tipo (s) es uno de los métodos más simples para componer tipos.

Otro caso en el que heredas de una clase que no tiene funciones virtuales, pero sirve como " tipo de " Una interfaz, es el polimorfismo estático (técnicas como CRTP, donde la clase ConcreteA: BaseA). No necesitan las funciones virtuales, porque todo se resuelve en tiempo de compilación.

Sin embargo, si desea tratar su tiempo de ejecución de clase de manera polimórfica, realmente debería hacer que al menos un método sea virtual, y ese sería el destructor. Hay excepciones, pero raras.

Incluso cuando tienes una jerarquía polimórfica, a veces derivas de clases concretas. Un ejemplo sería un SingleLineEdit derivado de TextEdit. Sin embargo, esto es un poco peligroso, porque rompe la encapsulación de la clase padre (por ejemplo, sus métodos pueden esperar algunos detalles de implementación, y debe respetarlos y preservarlos en la subclase, lo que puede ser complicado, ya que son detalles de implementación que pueden cambiar sin previo aviso en la próxima versión, etc.)

Answer 2

Yo diría que el concepto clave de la programación orientada a objetos es el polimorfismo. Si heredar de una clase en particular no le permite aprovechar el polimorfismo, ¿cuál es el punto de heredar? Entonces, si no hay métodos para anular, entonces no haga una subclase. Solo estarías aumentando la complejidad de tu código. Si desea muchas de las mismas funciones, simplemente ajuste la clase existente por su cuenta.