Sortir de la Zone de Douleur - NDepend

Question

Je dirigeais simplement un de mes projets via NDepend et le rapport mettait mon ensemble dans le coin de la zone de douleur. Je me demandais juste si c'était quelque chose dont je devrais m'inquiéter.

Que signifie vraiment la zone de douleur? Cela ne signifie-t-il pas qu'il y a beaucoup de couplage et que les choses ne peuvent pas changer très facilement.

J'ai récemment enlevé beaucoup d'interfaces et scellé beaucoup de classes car je ne veux pas que l'utilisateur prolonge l'API (seulement dans quelques endroits). C'est un .NET Wrapper pour un objet com, donc il n'y a pas beaucoup de besoin pour l'utilisateur d'étendre quelque chose.

Quels sont les bons moyens de me sortir de la zone douloureuse?

Merci

Answer 1

Je pense que Scott Hanselman avait écrit un billet assez long au sujet NDepend et ses implications de la zone

http://www.hanselman.com/blog/ExitingTheZoneOfPainStaticAnalysisWithNDepend.aspx

Comme il a dit, et je suis d'accord, un ensemble planant dans la zone de la douleur est pas nécessairement une mauvaise chose. Il est cependant, une indication des changements requis de votre part lorsque le jour de la décision vient d'utiliser un autre composant (COM ou autre) pour remplir cette même couche de fonctionnalité.

La question à poser est probablement, "quelle est la probabilité que nous allons échanger cette couche pour un autre cadre/bibliothèque?"

Answer 2

L'idée de la zone de la douleur est de détecter les composants que les deux: béton -Est (i.e. leurs utilisateurs sont binded avec des classes au lieu d'interfaces) -Est populaires (i.e. ils sont utilisés par un grand nombre d'autres composants).

Populaires se réfère à la notion de stabilité. Un composant est stable si, lorsqu'il est modifié, il casse beaucoup d'autres composants qui l'utilisent. En un mot: Popular = Stable

Une autre idée est que les interfaces sont moins sujettes aux changements que les classes. C'est pourquoi il est communément admis qu'il est préférable d'utiliser une interface plutôt qu'une classe, vous avez moins de chance d'être "statiquement" cassé + vous avez moins de chance d'être "sémantiquement" brisé, puisque votre code n'est pas censé être lié à tous les détails d'implémentations (qui sont fortement sujets à des changements). En conséquence, être concret + stable expose un composant à une douleur potentielle de développement: il est très sujet aux changements + chaque changement peut potentiellement casser beaucoup de code.

Dans votre cas et dans d'autres cas, être dans la zone de douleur n'est pas nécessairement une mauvaise chose. L'important est d'être à la fois conscient de ce fait + si en effet votre composant provoque la douleur, puis retournez votre code aux interfaces.