¿Cuándo heredar de una clase te duele más tarde?

Question

¿Puede proporcionar escenarios cuando heredamos de una clase, funciona por un tiempo, pero luego algo más cambia e introduce un error? me ocurrió con la siguiente situación:

• para implementar rectángulo-con-agujero, que heredamos de la clase Rectángulo. En el constructor, comprobamos que el agujero está dentro del rectángulo
• Más tarde alguien añade un nuevo método de cambio de tamaño para rectángulo clase. No verifican si el agujero todavía está adentro.
• Después de cambiar el tamaño, podemos tener rectángulo-con-agujeros con agujeros no dentro de los rectángulos, lo cual es un error.

¿Cuáles son los otros problemas que debería tener cuidado si elijo usar herencia de objetos en C#.

Answer 1

Hay muchas maneras de un cambio a una clase base pueden afectar el comportamiento de la clase derivada. ¿Qué pasa si el autor de repente decidió hacer la clase sealed por ejemplo?

Como cualquier interfaz, necesita ser estable para que los consumidores no requieran modificaciones.

La "regla" primaria con herencia es el Principio de Substición Liskov. Esto establece que la clase derivada debe ser sustituible por la clase base u otras clases derivadas de ella.

Este caso rompe esta regla en la cara, ya que un rectángulo con un agujero no es un rectángulo.

Por lo general, es mejor utilizar interfaces para dividir el comportamiento en trozos implementables sensibles. Tales interfaces generalmente se nombran con adjetivos en lugar de nombres. Por ejemplo, tiene sentido que se representen tanto un rectángulo como un rectángulo con un agujero, por lo que una interfaz puede ser IRenderable. Si se puede cambiar el tamaño, puede tener un IResizable, etc. Estos pueden agregarse en un IShape, pero debe tener cuidado de que su definición de Forma defina solo los comportamientos en su dominio problemático.

Derivar directamente de otra clase puede ser peligroso ya que entonces estás obligado por el comportamiento de esa clase. Si realmente necesita hacerlo, puede ser mejor extraer la implementación que necesita en una clase base común (por ejemplo, Rectangle : RectangleImplementation, IShape).

Answer 2

Lo que usted describe es una de las trampas de la herencia.

Otro escollo es una jerarquía de herencia de profundidad. Stackoverflow thread en composition over inheritance.

Answer 3

no llame a un método virtual en un constructor. Vea las publicaciones de Eric Lippert al respecto (part 1 y part 2).

Answer 4

Esto se conoce como brittle base class problem.

Otro problema potencial con la herencia en general es cuando desea usar su propia clase base, pero un marco requiere una clase base específica (por ejemplo, ContextBoundObject) en lugar de una interfaz.

Answer 5

Es por eso que los proféticos diseñadores del lenguaje C# agregaron palabra clave al idioma. Use juiciosamente.

Y use contratos de código para probar sus invariantes y obtener una advertencia temprana sobre la rotura.

Answer 6

Mejor uso - Patrón de decorador en este tipo de casos. Esto proporciona una mejor forma de extensión.

Esto se puede implementar mediante el siguiente diagrama:

El objeto rectángulo se creará y se envuelve en un objeto HoleDecorator que será responsable de proporcionar el agujero. Cuando se hace el cambio de tamaño del rectángulo, se llamará el cambio de tamaño de HoleDecorator, esto llamará primero al objeto de cambio de tamaño del rectángulo y luego llamará a AddedBehavior para el Hole Decorator que especificará qué hacer con el agujero cuando el componente principal esté redimensionado

Answer 7

Creo que esto no está relacionado con C# o la herencia. No importa lo que haga, este es un problema inevitable del desarrollo de software.

La mejor y sencilla solución es construir su código diariamente y realizar unit testing.