existen mejores prácticas con respecto a la profundidad máxima de la jerarquía de herencia para un marco y las pautas sobre cuándo usar múltiples niveles de herencia o unirlos en una sola clase?¿Cuántos niveles de herencia
Algunas referencias a prácticas/ejemplos establecidos que funcionaron bien en el mundo de Java serían agradables en las respuestas ya que esto es desde la perspectiva de la comunidad y los marcos que rodean a Java.
Puedes estar buscando una buena regla como "no más de 5 niveles de herencia", pero realmente dudo que existe tal regla. Los objetos usualmente modelan entidades del mundo real y la comunidad de todas esas entidades nunca estuvo de acuerdo con una regla (hasta donde yo sé) ...
Una "mejor práctica" es definitivamente: favorecer la composición sobre la herencia. Siguiendo esta pauta: define una interfaz e implementaciones sin más superclases. Todos los campos y métodos comunes vienen con comportamiento y strategies
Por otro lado, algunas veces modelamos entidades del mundo real o estructuras que ya vienen con una jerarquía profunda de entidades. La clasificación de los animales es un ejemplo o algebraic structures. Un marco para modelar tales estructuras existentes requeriría una jerarquía de clases profunda porque debería seguir el mundo real solo para ser comprensible.
Por supuesto, hay problemas con la clasificación de los animales como una estructura de herencia. –
Odio ver esto * favorecer la composición sobre la herencia * en todas partes, fuera del contexto. Usas la composición donde importa y la herencia donde importa. La regla real debe ser * no use la herencia como mecanismo de intercambio de código. * – nawfal
Creo que, desde el punto de vista del mantenimiento, una jerarquía de herencia tan superficial como pueda gestionar es el camino a seguir. Hacer un seguimiento de los errores a través de múltiples niveles jerárquicos, y luego tener que descubrir en qué nivel deben ser reparados puede ser complicado.
Yo diría que es exactamente lo contrario: al colapsar las clases en menos clases más grandes, hace que la depuración sea más difícil. – aioobe
@aioobe - Esto es cierto, pero también es posible ir demasiado lejos y dividir las cosas demasiado lejos, donde la composición sería favorable, en lugar de la herencia. He estado trabajando en algunas jerarquías complejas donde esto ha sucedido ... – Paddy
En mi opinión, cada clase derivada es "una clase propia", y los clientes de esta clase, incluidas las subclases) en general no deberían molestarse o estar interesados en cuántas clases hay entre esta clase y el Object clase.
Por lo tanto, mi respuesta sería: No, deje que la jerarquía sea tan profunda como debe ser, siempre que tenga sentido/parezca lógica. No permita que la profundidad de la jerarquía influya en la decisión de colapsar dos clases o no. Como cada subclase es un refinamiento de su clase base, mi experiencia dice que rara vez tiene sentido tener profundidades de más de 5 o 6 clases.
Para que quede claro: Como han señalado otros, debe favorecer la composición por encima de la herencia. Sin embargo, para mí, eso parece responder a una pregunta ligeramente diferente.
Según this article, la profundidad máxima en la API estándar de Java es 9.
Esto es simplemente incorrecto. La herencia es un factor de complejidad bien conocido. – Reza
¿Estás diciendo que al colapsar las clases obtienes un programa menos complejo? – aioobe
Cualquier métrica de complejidad de código tiene un factor para la profundidad de herencia de clase. De acuerdo con MS MSDN, cuanto más profunda sea la jerarquía, más difícil será entender dónde se definen y/o redefinen determinados métodos y campos. – Reza
Usted debe pensar primero en la claridad del código que está escribiendo. Tener más nivel de profundidad hará que el código sea más fácil de leer y mantener, o lo hará más difícil. Mucho dependiendo del problema que estás tratando de resolver.
Como sugieren otros carteles, puede hacer que la profundidad sea demasiado profunda o demasiado profunda. Este es un problema de oro en mi humilde opinión.
Lo mejor es que cada clase se ocupa de un montón de cosas similares.
Cada método dentro de esta clase se ocupa de una acción/comportamiento.
Mira esta refcard de DZone: http://refcardz.dzone.com/assets/download/refcard/54c22c8b0a53591ea9e0504fdfd4bada/rc130-010d-designing-quality_0.pdf
A * montón * de cosas similares? ¿No te gusta el Principio de Responsabilidad Individual? –
regla general es la más profunda de la jerarquía, más difícil podría ser para entender donde se definen y/o redefinen los métodos y campos particulares.
Pero además de la herencia hay otros factores que debe tener cuidado para mantener la complejidad de su código manejable.
El mejor enfoque es utilizar una herramienta de métricas de código y tratar de equilibrio entre los diferentes factores (líneas de código, clase y desacoplamiento ...)
Por lo que he visto (nota: esto no es una opinión oficial, solo mis observaciones), 3-4 es un máximo razonable.
También, recordar una parte importante de Effective Java: Composición
favor sobre la herencia
No hay mejores prácticas con respecto a la profundidad máxima de la herencia. En lugar de buscarlo en volumen, esta es la regla general en lo que respecta a la herencia en java (y cualquier lenguaje OO para el caso).
1_ Antes de implementar la herencia, compruebe si la relación "es una" es verdadera. El cargador es un auto. (Así que la herencia está bien). Si haces esto, entonces no terminarás con un gran árbol de herencia de todos modos. (La rueda no es un automóvil, entonces la herencia aquí es incorrecta)
2_ Si la relación "es una" falla o si tiene ambigüedad, entonces la herencia probable no es el camino. Debe identificar las características comunes entre sus clases y usar la composición (refactorizar el código común a una nueva clase).
3_ si desea establecer una jerárquica de tipo, entonces debe ir con herencia de interfaz (tipo) no herencia de nivel de clase. (Puede ser que algunas de estas afirmaciones necesiten más explicación, pero para eso es probable que necesites tomar un libro.)
En cuanto a las mejores prácticas, también se debe considerar el rendimiento (uso de memoria).
Utilizará más memoria cuando tenga una jerarquía profunda de clases (no abstracta). Al igual que la creación de un nuevo objeto de último hijo de 3 niveles de herencia utilizará MENOS MEMORIA que la de 9 niveles de herencia. Según la naturaleza de la aplicación, este punto se puede considerar, además de otras publicaciones.
¿No podría decirse lo mismo de la codificación orientada a objetos frente a la codificación de procedimientos? – Cornelius
Tan poco profundo como sea posible, tan profundo como sea necesario – CodesInChaos