Jerarquía de herencia de clases profundas: ¿mala idea?

Question

esperando que un gran maestro pueda arrojar algo de luz. La descripción general muy alta es que no soy un principiante en la codificación, pero aún soy nuevo en OOP. Este conjunto de clases de mensajes está en el corazón de una gran aplicación de simulación que estamos escribiendo, y no quiero hacerlo estúpidamente: esta interfaz corta la aplicación a la mitad, desde el secuenciador al ejecutador y viceversa.

Mi pregunta es si es o no una mala idea tener una jerarquía de herencia tan profunda (la imagen aún no está desarrollada, podría ir 5 o 6 al final). Esto es opuesto a que algunas de las clases secundarias solo tengan una asociación dirigida a su clase principal, en lugar de heredar.

He leído que una jerarquía de herencia profunda no es una buena idea, y que si una clase hija hereda simplemente para tener los datos del padre, entonces simplemente debe incluir el padre como datos en el hijo, pero yo ' Estoy teniendo dificultades para entender por qué. ¿Qué cosa mala nos va a pasar si decidí hacer una jerarquía de herencia de siete o algo así? Claramente, hay un pequeño golpe de rendimiento, y cambiar las cosas en la parte superior de la jerarquía va a tener enormes ondas en toda la aplicación, pero aparte de eso, no veo un problema. Además, poco me importan las pequeñas diferencias en el rendimiento.

(pregunta extra:? ¿Hay un paquete off-the-shelf que se encarga de este tipo de cosas tenemos la mayor parte de las simulaciones físicas bajo nivel manipulados, pero el programa de secuenciación que vamos a tener para escribir. Solo tengo esta sospecha de que lo que he presentado es muy similar a lo que hicieron 10,000 desarrolladores de simulación antes que yo.)

(pregunta extra 2: cualquier maestro de ambos sistemas de simulación y programación OOP, que no odiaría vivir en Los Ángeles? Estamos contratando.)

Answer 1

que si una clase hija hereda simplemente para tener los datos del padre

Esto es una mala idea. Existe la comprensión de que se definen clases base como el más genérico de los contratos que un conjunto de clases (concretas) van a honrar. Esto generalmente significa que su contrato tiene aproximadamente comportamiento y no implementación.

¿Qué mal nos va a pasar si decidí hacer una jerarquía de herencia de siete profundidades o algo así?

Los principales problemas aquí son mundanos:

• clases base frágiles (los cambios en la base son una pesadilla para la derivada)
• Aumento de acoplamiento (con demasiadas clases base viene estrecho acoplamiento)
• La encapsulación se debilita
• Problemas de prueba (los métodos reemplazados a nivel de hoja no pueden simplemente probarse para reproducir correctamente el comportamiento del usuario final siempre debido a múltiples llamadas encadenadas aquí y allá)
• Mantenimiento (proviene de acoplamiento fuerte)

(Usted muchos quieren leer este documento en Why Ada isn't popular, en particular, del artículo 6, párrafo 6.)

¿Existe un paquete listo para usar que maneje este tipo de cosas?

No estoy seguro de lo que está buscando, pero si está buscando un simplificador de jerarquía automatizado, entonces no conozco ninguno. Además, si existe tal paquete, dependerá en gran medida del idioma que prefiera y no haya mencionado uno.

Tenga en cuenta que la mayoría de las veces estos problemas se pueden resolver al buscar alternativas como la agregación o los rasgos o la inyección de dependencia o lo que sea. Estos son problemas de tiempo de diseño y son típicamente (IMO) mejor planchado en una pizarra que con un compilador y millones de LOC.

Answer 2

Al ver esta pregunta bastante tarde, pero he tenido muchas reflexiones sobre esto y he sido mordido con jerarquías de herencia profundas. Una razón por la que son malos es porque inevitablemente obtendrás la clasificación equivocada a medida que especializas las muchas subclases. Sin embargo, una vez que tenga la estructura de clases en su lugar, será difícil cambiar porque al hacerlo se rompería el código del cliente.

He escrito sobre esto here.