¿Es mala forma referirse a un tipo derivado en un tipo base?

Question

Tengo una estructura de árbol de categoría/archivo. Ambas categorías y archivos pueden tener padres, por lo que los derivé de una clase base común que tiene una propiedad Parent. Dado que todos los padres, obviamente, siempre serán categorías (los archivos no pueden ser padres), parece tener sentido hacer que la propiedad principal del nodo sea del tipo CategoryNode.

¿Es malo que la clase base se refiera a la clase derivada? Si es así, ¿por qué? ¿Cuál es una mejor manera de estructurar esto, si es así?

class Node { 
    public CategoryNode Parent {get; set;} 
} 

class File : Node { 
    ... 
} 

class CategoryNode : Node { 
    ... 
} 

Answer 1

Si la propiedad Parent es realmente una propiedad común de todos los descendientes y siempre de tipo CategoryNode, no es un problema. Semánticamente hablando es correcto y técnicamente creo que también es correcto tan pronto como permaneces en la misma biblioteca (para evitar referencias circulares).

Esto puede ser un problema cuando se escribe código como este:

// BAD CODE 
if(myProp is subclassA) 
{ ... 
} 
else if (myProp is syubclassB) 
{ ... 
} 

Este código es malo, porque se pierde la ventaja de la herencia.

Incluso en .Net Framework existen dichos constructos. El primer ejemplo que viene a mi mente es la propiedad XObject.Parent.

XElement hereda XObject y XObject publica una propiedad de tipo XElement. Igual que tu fragmento.

Answer 2

La clase base no debería saber quién se deriva de ella.

Si tiene un caso así, probablemente no desee la herencia. Deberías usar alguna forma de acoplamiento.

El archivo y CategoryNode debe contener un miembro Node en su caso.

Answer 3

Otras opciones serán cambiar la jerarquía de clases para convertir el CategoryNode en una clase raíz (a) o cambiar el tipo de propiedad a Node (b).

Ambas posibilidades no son buenas: (a) El archivo tendrá todas las funcionalidades que tiene CategoryNode que no necesita. (b) Ocultará el tipo de objeto (que siempre es CategoryNode). Esto puede seguir a los errores de conversión no válidos en otro lugar en su código. Por ejemplo, si olvida que siempre hay una instancia de CategoryNode.

Teniendo esto en cuenta, creo que el código actual es correcto.

Answer 4

Se podría hacer ...

interface IParent { 
    ... 
} 

class Node { 
    public IParent Parent {get; set;} 
} 

class File : Node { 
    ... 
} 

class CategoryNode : Node, IParent { 
    ... 
} 

De esta forma, no es necesario hacer referencia a un objeto derivado de la clase base, además, es más flexibles en lo que realmente puede llegar a ser un padre , en caso de que obtenga tipos de objetos adicionales en un momento posterior. Además, cualquier funcionalidad que sea relevante solo para un padre se puede declarar en esa interfaz.