Métriques de code - Profondeur d’héritage (DIT, depth of inheritance tree)

Cet article vous permet de découvrir l’une des métriques conçues spécifiquement pour l’analyse orientée objet : la profondeur d’héritage. La profondeur d'héritage, ou DIT (depth of inheritance tree), est définie comme « la longueur maximale entre le nœud et la racine de l'arborescence » CK. Vous pouvez visualiser cela à l’aide d’un exemple simple. Créez un projet de bibliothèque de classes et, avant d’écrire du code, calculez les métriques de code en choisissant Analyser > Calculer la métrique du code pour la solution.

Étant donné que toutes les classes héritent de System.Object, la profondeur a actuellement la valeur 1. Si vous héritez de cette classe et examinez la nouvelle classe, vous pouvez voir le résultat suivant :

Notez que plus le nœud est situé vers le bas de l’arborescence (Class2 dans ce cas), plus la profondeur d’héritage est élevée. Vous pouvez continuer à créer des enfants (et donc augmenter la profondeur) autant que vous le souhaitez.

Hypothèses

La profondeur d’héritage est basée sur trois hypothèses fondamentales CK :

1. Si une classe est située profondément dans la hiérarchie, elle héritera probablement d’un plus grand nombre de méthodes. Il est alors plus difficile de prévoir son comportement.

2. Les arborescences plus profondes augmentent la complexité de conception, car davantage de classes et de méthodes sont impliquées.

3. Les classes situées plus profondément dans l’arborescence sont plus susceptibles de réutiliser des méthodes héritées.

Il découle des hypothèses 1 et 2 qu’une valeur de profondeur élevée n’est pas une bonne chose. Vous ne seriez pas sur la bonne voie. Toutefois, suivant l’hypothèse 3, une valeur de profondeur élevée est une bonne chose pour une éventuelle réutilisation du code.

Analyse

Voici comment lire la métrique de profondeur :

• Valeur de profondeur faible

  Une valeur de profondeur faible implique moins de complexité, mais également un moindre potentiel de réutilisation du code avec l’héritage.

• Valeur de profondeur élevée

  Une valeur de profondeur élevée implique un plus grand potentiel de réutilisation du code avec l’héritage, mais également une complexité accrue avec un plus grand risque d’erreur dans le code.

Analyse du code

L’analyse du code inclut une catégorie de règles de maintenabilité. Pour plus d’informations, consultez Règles de maintenabilité. Quand vous utilisez une analyse du code héritée, l’ensemble de règles Extended Design Guideline inclut une catégorie de maintenabilité :

La catégorie de maintenabilité inclut une règle pour l’héritage :

Cette règle émet un avertissement quand la profondeur d’héritage atteint ou dépasse la valeur 6. Elle est donc très utile pour éviter un héritage excessif. En savoir plus sur cette règle, consultez CA1501.

En résumé

Quand les valeurs de profondeur d’héritage sont élevées, le risque d’erreur est accru. En revanche, des valeurs faibles impliquent un risque d’erreur moindre. Quand les valeurs de profondeur d'héritage sont élevées, le potentiel de réutilisation du code avec l'héritage est également plus élevé. En revanche, des valeurs faibles impliquent un plus faible potentiel de réutilisation du code par le biais de l'héritage. En raison du manque de données disponibles, il n’existe actuellement aucun standard communément accepté à l’égard des valeurs de profondeur d’héritage. Même les études récentes n'ont pas permis de révéler suffisamment de données pour déterminer une valeur fiable qui pourrait être utilisée comme un standard pour cette métrique Shatnawi. Bien qu’il n’existe aucune preuve empirique à l’appui, plusieurs ressources suggèrent une valeur limite supérieure de profondeur d’héritage autour de 5 ou 6. Par exemple, consultez https://www.devx.com/architecture-zone/45611/.

Références

CK

Chidamber, S. R. et Kemerer, C. F. (1994). A Metrics Suite for Object Oriented Design (IEEE Transactions on Software Engineering, Vol. 20, N° 6). Extrait le 14 mai 2011 du site web de l’Université de Pittsburgh : http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

Krishnan

Subramanyam, R. et Krishnan, M. S. (2003). Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Implications for Software Defects (IEEE Transactions on Software Engineering, Vol. 29, N° 4). Extrait le 14 mai 2011, obtenu à l’origine sur le site web de l’Université de Massachusetts Dartmouth https://ieeexplore.ieee.org/abstract/document/1191795

Shatnawi

Shatnawi, R. (2010). A Quantitative Investigation of the Acceptable Risk Levels of Object-Oriented Metrics in Open-Source Systems (IEEE Transactions on Software Engineering, Vol. 36, N° 2).