Métriques de code - Profondeur de l’héritage (DIT)

Dans cet article, vous allez découvrir l’une des métriques conçues spécifiquement pour l’analyse orientée objet : Profondeur de l’héritage. La profondeur de l’héritage, également appelée profondeur de l’arborescence d’héritage (DIT), est définie comme « la longueur maximale du nœud à la racine de l’arborescence ». Vous pouvez le voir avec 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 les > métriques de code pour la solution.

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

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

Hypothèses

La profondeur de l’héritage est prédicée sur trois hypothèses fondamentales :

1. Plus une classe est profonde dans la hiérarchie, plus le nombre de méthodes qu’il héritera probablement, ce qui rend plus difficile la prédiction de son comportement.

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

3. Les classes plus approfondies de l’arborescence ont un plus grand potentiel de réutilisation des méthodes héritées.

Les hypothèses 1 et 2 vous indiquent que le fait d’avoir un nombre plus élevé pour la profondeur est mauvais. Si c’est là que cela s’est terminé, vous serez en bonne forme ; toutefois, l’hypothèse 3 indique qu’un nombre plus élevé de profondeurs est favorable à la réutilisation du code.

Analyse

Voici comment lire la métrique de profondeur :

• Nombre faible pour la profondeur

  Un nombre faible pour la profondeur implique moins de complexité, mais aussi la possibilité de réduire la réutilisation du code par héritage.

• Nombre élevé pour la profondeur

  Un nombre élevé de profondeur implique un potentiel plus élevé pour la réutilisation du code via l’héritage, mais également une complexité plus élevée avec une probabilité plus élevée d’erreurs dans le code.

Analyse du code

L’analyse du code comprend une catégorie de règles de maintenance. Pour plus d’informations, consultez règles de maintenance. Lors de l’utilisation de l’analyse du code hérité, l’ensemble de règles de recommandations de conception étendue contient une zone de facilité de maintenance :

À l’intérieur de la zone de maintenabilité se trouve une règle d’héritage :

Cette règle émet un avertissement lorsque la profondeur de l’héritage atteint 6 ou plus. Il s’agit donc d’une bonne règle pour empêcher l’héritage excessif. Pour en savoir plus sur la règle, consultez CA1501.

Tout assembler

Les valeurs élevées pour DIT signifient que le risque d’erreurs est également élevé, les valeurs faibles réduisent le risque d’erreurs. Les valeurs élevées pour DIT indiquent un plus grand potentiel de réutilisation du code via l’héritage, tandis que les valeurs faibles suggèrent moins de potentiel de réutilisation via l’héritage. En raison d’un manque de données suffisantes, il n’existe actuellement aucune norme acceptée pour les valeurs DIT. Même les études effectuées récemment n’ont pas trouvé suffisamment de données pour déterminer un nombre viable qui pourrait être utilisé comme nombre standard pour cette métrique Shatnawi. Bien qu’il n’y ait aucune preuve empirique pour la soutenir, plusieurs ressources suggèrent qu’un DIT d’environ 5 ou 6 doit être une limite supérieure. Par exemple, consultez https://www.devx.com/architecture-zone/45611/.

Références

CK

Chidamber, S. R. & Kemerer, C. F. (1994). Une suite metrics pour la conception orientée objet (transactions IEEE sur l’ingénierie logicielle, vol. 20, no 6). Récupéré le 14 mai 2011, à partir du site web de l’Université de Pittsburgh : http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

Krishnan

Subramanyam, R. & Krishnan, M. S. (2003). Analyse empirique des métriques CK pour la complexité de conception orientée objet : implications pour les défauts logiciels (Transactions IEEE sur l'Ingénierie Logicielle, vol. 29, n° 4). Récupéré le 14 mai 2011, obtenu à l’origine à partir du site web de l’Université du Massachusetts Dartmouth https://ieeexplore.ieee.org/abstract/document/1191795

Shatnawi

Shatnawi, R. (2010). Examen quantitatif des niveaux de risque acceptables des métriques orientées objet dans les systèmes open source (Transactions IEEE sur l’ingénierie logicielle, vol. 36, n° 2).