Devrais-je me préoccuper davantage du couplage entre colis ou entre unités de distribution?

Question

J'ai consulté des métriques pour le couplage et également Consultez DSM .

L’un des outils que j’ai utilisés concerne le couplage entre "modules" et un module constituant une unité de distribution (dans ce cas, un assemblage .net).

Je pense que je devrais être plus intéressé par le couplage entre les paquets (ou les espaces de noms) qu'avec les unités de distribution.

Devrais-je me préoccuper davantage du couplage entre les packages / espaces de noms (assurez-vous que les abstractions ne dépendent que d’abstractions, les types concrets dépendent d’abstractions et qu’ils ne sont pas des cycles dans les dépendances, ce qui facilite la refactorisation et l’extension) ou devrais-je me préoccuper des si je peux déployer de nouvelles versions sans avoir à mettre à jour les unités de distribution inchangées?

Qu'est-ce que quelqu'un d'autre mesure?

Pour ce que cela vaut, je ressens déjà que si je me concentre sur le couplage paquet / espace de nom, alors l’unité de couplage de distribution sera gratuite ou du moins plus simple.

Answer 1

Tout d'abord, il est facile d'aller trop loin en examinant les dépendances et le couplage. Assurez-vous de ne pas trop compliquer les choses.

Avec cette clause de non-responsabilité, voici ce que je suggère.

La gestion des dépendances / couplages présente trois points de vue différents: 1) structure physique (c'est-à-dire dépendances d'assemblage) 2) structure logique (dépendances des espaces de noms) 3) structure de mise en œuvre (c'est-à-dire dépendances de classe)

Pour les applications volumineuses, vous devez au moins examiner les 3, mais vous pouvez généralement définir des priorités.

Pour les applications déployées sur le client, le numéro 1 peut être très important (c'est-à-dire, par exemple, pour les plug-ins). Pour les applications déployées au sein de l'entreprise (c'est-à-dire asp.net), l'élément n ° 1 s'avère généralement sans importance (à l'exclusion des frameworks réutilisés dans plusieurs applications). Vous pouvez généralement déployer l’ensemble de l’application assez facilement pour ne pas supporter les frais généraux d’une structure compliquée pour # 1.

Le point 2 a tendance à être davantage un problème de maintenabilité. Connaissez les limites de vos couches et leur relation avec les espaces de noms (c’est-à-dire que vous ne faites qu'une couche par espace de noms ou que vous êtes empaqueté différemment au niveau logique). Parfois, des outils peuvent vous aider à imposer vos limites de couche en examinant la structure de dépendance logique.

L'article n ° 3 concerne vraiment la conception de bonnes classes. Tout bon développeur doit déployer beaucoup d'efforts pour s'assurer qu'il n'assume que les dépendances appropriées dans ses classes. C’est plus facile à dire qu’à faire et c’est typiquement une compétence qui doit être acquise au fil du temps.

Pour être un peu plus proche du cœur de votre question, le premier élément concerne la présentation des projets dans la solution VS. Donc, ce n'est pas un élément à mesurer. C'est plutôt quelque chose que vous avez configuré au début et que vous laissez courir. L'élément n ° 2 est quelque chose que vous pourriez utiliser à l'aide d'un outil pour vérifier pendant les générations si les développeurs ont enfreint les règles. C'est plus un contrôle qu'une mesure vraiment. L'élément n ° 3 est vraiment celui que vous voudriez bien examiner pour mesurer. Trouver les classes dans votre base de code qui ont beaucoup de couplage va être un problème pour l'avenir, assurez-vous de la qualité de ces gars. En outre, mesurer à ce niveau vous permet de mieux comprendre la qualité (globale) de la base de code au fur et à mesure de son évolution. De plus, cela peut vous donner un drapeau rouge si quelqu'un vérifie du code vraiment torride dans votre base de code.

Donc, si vous souhaitez définir des priorités, jetez un coup d’œil aux n ° 1 et n ° 2. Savoir à quoi ils devraient ressembler. Mais pour la plupart des applications, l'élément n ° 3 devrait prendre le plus de temps.

Cette réponse, bien sûr, exclut les très gros frameworks (comme le .NET BCL). Ces bébés doivent faire très attention à # 1. : -)

Sinon, vous vous retrouvez avec des problèmes comme celui-ci: "Les versions actuelles du .NET Framework incluent une variété de bibliothèques basées sur une interface graphique qui ne fonctionneraient pas correctement dans Server Core" http://www.winsupersite.com/showcase/win2008_ntk.asp

Vous ne pouvez pas exécuter .NET sur une installation sans interface graphique de Windows Server 2008 car le framework prend en charge les bibliothèques d'interface graphique ...

Une dernière chose. Assurez-vous de bien connaître les principes qui sous-tendent une bonne gestion de la dépendance / couplage. Vous pouvez trouver une belle liste ici:

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 2

Les cycles de couplage et de dépendance entre les unités de distribution sont plus "fatals" cela peut rendre très difficile le déploiement de votre programme - et parfois, il peut aussi être très difficile de même compiler votre programme.

vous avez généralement raison, une bonne conception de niveau supérieur qui divise le code en packages logiques et des dépendances claires et prédéfinies vous permettra de résoudre le problème, il ne manque que la séparation correcte des packages en unités de distribution.