Quel est un bon moyen de montrer la relation entre les classes et les interfaces faiblement couplées?

Question

J'ai présenté les principes SOLID à mon équipe et ils comprennent et sont enthousiastes à l'idée d'utiliser les principes. Je leur ai donné quelques projets qui ont déjà été recréés pour utiliser ces principes. Le plus gros problème que je vois s'ils ont du mal à voir les connexions entre les classes très faiblement couplées au sein du projet. Même si je crée un diagramme de classes, il ne montrera aucune connexion. Un projet particulier auquel je fais référence utilise aussi Dependency Injection et la configuration XML pour les implémentations. Bien que cela ait un but, il est encore plus difficile pour eux de savoir quelle classe est utilisée. Quelle est la meilleure façon de montrer visuellement les relations entre les classes et comment elles sont utilisées dans le projet ?!

Modifié: 2008/10/24 20:40

Basé sur le commentaire UML je tentais de se tourner vers le haut dans le diagramme de classes Visual Studio pour construire un modèle d'une application. Je peux donner des descriptions de chaque interface mais je ne suis toujours pas sûr qu'elles soient clairement connectées.

Answer 1

diagrammes d'interaction UML peuvent montrer explicitement de telles relations: cela suppose que ...

diagrammes de classes UML peuvent montrer à la fois cette classe utilise cette interface et cette interface est implémentée par cette classe.

Maintenant de tels diagrammes sont des instructions "ponctuelles" concernant un choix particulier fait pour une exécution particulière, quelles injections particulières ont pu se produire. Donc, dans une certaine mesure en fournissant les diagrammes, vous vous éloignez du design généralement flexible que vous utilisez, mais je peux comprendre que les gens trouvent de telles images utiles. J'essaie de penser aux aspects de la conception en relation avec les interfaces, je ne devrais vraiment pas avoir besoin de comprendre «comment» les méthodes décrites par une interface fonctionnent, comprendre ce que font les implémentations. Onde idée est que nous devons adopter une approche de la boîte noire à nos dépendances. Je recommande donc d'encourager les gens à ne pas avoir besoin de tels diagrammes, plutôt que de penser en termes de responsabilités. (ce qui est très bien jusqu'à ce que les choses ne fonctionnent pas, alors le diagnostic pourrait bien exiger plus) mais considérez: quand vous utilisez de nombreuses fonctionnalités du système d'exploitation et .NET, savez-vous réellement ce qui se passe réellement? Pouvez-vous adopter la même approche mentale avec d'autres parties du code de votre application?

Answer 2

J'ai tendance à ne penser aux interfaces que lorsqu'il s'agit de relations, donc je ne peux pas vraiment vous aider avec de larges aperçus/diagrammes de classes pour les types concrets. Comme quelqu'un l'a déjà fait remarquer, si vous voulez montrer des types concrets sur le diagramme, cela ne sera pertinent que pour un instantané d'une exécution particulière - il changera chaque fois que le graphe d'objet est câblé différemment.

Je pense qu'il est généralement plus utile de disposer les interfaces dans les diagrammes, puis de parcourir la base de code pour trouver les implémentations.Une astuce qui rend le code navigation beaucoup, beaucoup plus simple:

Obtenez le ReSharper plugin for Visual Studio et utiliser les raccourcis suivants (lorsque votre caret est sur une classe/interface):

Alt +Accueil - aller à la base/Interface

Alt +Fin - aller à l'interface dérivés/types d'application

Ces deux raccourcis sont absolument essentiels pour parcourir une base de code avec beaucoup de couplage lâche.