DIT (Depth of Inheritance Tree)
DIT es otra de las métricas propuestas por Chidamber y Kemerer. Como su propio nombre indica calcula para cada clase su distancia o profundidad respecto a la clase más alta en la jerarquía (en el caso de java, por ejemplo será Object, que es superclase (directa o indirectamente) de todas las clases).
DIT es otra medida de complejidad, ya que conforme se va heredando de clases que heredan a otras, es mayor la «carga» de métodos que puede soportar la clase y si por ejemplo la métrica RFC cuenta los métodos propios de la clase, estos métodos heredados también podrían considerarse como propios y por tanto ser tenidos en cuenta como un factor de complejidad.
Utilizando el mismo razonamiento la herencia podría considerarse como otra forma de acoplamiento, por lo que una modificación en la definición de un método de una clase superior o de su comportamiento pueden tener impacto en clases inferiores de la jerarquía cuando se instancian objetos que hacen uso de dichos métodos. Como es lógico, existen determinadas estrategias de diseño y programación que pueden reducir el nivel de acoplamiento (de la misma manera que malas prácticas pueden incrementarlo).
En resumen, una clase que se encuentra en un nivel bajo en la jerarquía de herencias, tendrá teóricamente un comportamiento más impredecible que otras situadas en niveles más altos.
No se trata de criticar la herencia, ni mucho menos, ya que es uno de los pilares de la programación orientada a objetos y de la reutilización de código (algo fundamental para la reducción del número de errores y por tanto conseguir sistemas de mayor calidad, cuando se hereda de clases suficientemente probadas y documentadas y sobre todo para reducir los costes de desarrollo), sino de intentar explicar por qué una clase de una determinada aplicación que se encuentra en un nivel inferior en el árbol de herencias de la misma puede considerarse de mayor complejidad (desde este punto de vista, porque como he publicado en otros artículos, la complejidad de una clase puede verse desde muy diversas formas y esta es una más) que otra que se encuentra en un nivel superior.
En el caso de java, el hecho de que únicamente se pueda heredar cada vez de una clase (herencia simple) permite reducir la complejidad en el árbol de herencia (cierto es que la profundidad no varía, pero el hecho de que cada nodo pueda tener más de un nodo padre «multiplica» los atributos y métodos potencialmente heredables). Cierto es que en java existe se permite la implementación de más de una interfaz (y de esta forma conseguir una especie de herencia múltiple), pero desde mi punto de vista (supongo que puede haber otras opiniones) el nivel de complejidad que se añade es inferior a si se permitiese herencia múltiple.
Como siempre, surge la pregunta del millón, ¿a partir de qué profundidad podemos considerar este tipo de complejidad como un factor de riesgo para una clase? he estado consultando y parece que está bastante aceptado que a partir de una profundidad mayor o igual a 5 empieza a existir ese riesgo (también hay quienes incrementan ese riesgo a profundidades mayores o iguales a 8).
En resumen, no se puede «castigar» a nadie por intentar reutilizar y la herencia es fundamental para ello, no obstante no debemos olvidar que árboles de herencia de mucha profundidad hacen teóricamente más impredecible el comportamiento y funcionamiento de las clases situadas en niveles más bajos de la jerarquía, así como se incrementa su dependencia respecto de otras.
Jummp 
Desde mi punto de vista, el nivel de profundidad sería más significativo si se analizase junto a otros parámetros, como por ejemplo: número de métodos sobreescritos y sobrecargados, uso de los atributos de clases padre en las clases hijas (es decir, cómo de acoplada está la jerarquía), etc etc.
DIT me parece una métrica muy interesante, pero algo vacía sin condimentarla con esos otros aspectos relacionados.
¡Saludos!
Con los parámetros que comentas podría ser una métrica mucho más precisa para medir el acoplamiento. No me extrañaría nada encontrarme tarde o temprano con una métrica que mida la profundidad de herencia teniéndolas en cuenta, ya que ten en cuenta que a partir de las métricas de Chidamber y Kemerer surgieron diferentes versiones de las mismas, conforme se empezaron a hacer estudios sobre las mismas.
Oye, ¿a que me pongo y establezco formalmente la fórmula que determine la métrica «DIT Recacha»? 🙂 Peor sonaban Chidamber y Kemerer jejeje.
Pues la verdad es que suena bastante bien :-).
Pingback: CBO (Coupling Between Object Classes) « Jummp’s Blog