我已向我的团队介绍了SOLID原则，他们理解并对使用这些原则感到兴奋。
S - SRP - Single Responsibility Principle
O - OCP - Open/Closed Principle
L - LSP - Liskov Substitution Principle
I - ISP - Interface Segregation Principle
D - DIP - Dependency Inversion Principle
我已经给了他们一些已经重新考虑使用这些原则的项目。如果他们很难看到项目中非常松散耦合的类之间的联系，那么我看到的最大的问题。即使我创建了一个类图，它也不会显示任何连接。我所指的一个特定项目也使用依赖注入和XML配置来实现。然而，这有它的目的，它使他们更难找出甚至被使用的类。
可视化地显示类之间的关系以及它们在项目中的使用方式的最佳方法是什么？！
编辑：2008/10/24 8:40 PM
基于UML注释，我试图转向内置的Visual Studio类图来构建应用程序的模型。我可以给出每个界面的描述，但仍然不确定它们是否清晰连接。
答案 0 :(得分：2)
我倾向于仅在涉及到关系时考虑接口，因此我无法真正帮助您使用具体类型的广泛概述/类图。正如有人已经指出的那样，如果你想在图上显示具体的类型，它只与一个特定运行的快照相关 - 每次对象图的连线方式都会改变。
我认为在图表中布置接口通常更有帮助，然后浏览代码库以查找实现。使代码浏览的一个提示更简单：
获取ReSharper plugin for Visual Studio并使用以下快捷方式（当您的插入符号位于类/接口上时）：
Alt + Home - 转到基础/界面
Alt + 结束 - 转到派生/类型实现界面
这两个快捷方式对于浏览具有大量松耦合的代码库是绝对必要的。
答案 1 :(得分：1)
UML交互图可以明确地显示这种关系：这称为......
UML类图可以显示此类使用该接口，并且该接口由该类实现。
现在，这些图表是关于特定执行的特定选择的“时间点”陈述，特定注入可能已发生。所以在某种程度上提供图表，你正在摆脱你正在使用的通常灵活的设计，但我可以理解，人们确实发现这些图片有用。
我尝试考虑与接口相关的设计方面，我真的不应该理解接口所描述的方法“如何”工作，理解实现正在做什么。 Onde的想法是我们确实需要采用Black Box方法来处理依赖关系。所以我建议鼓励人们不要这样的图表，而是要考虑责任。 （这一切都很好，直到事情不起作用，然后诊断可能需要更多）但考虑：当你使用许多操作系统和.NET功能时，你真的知道真正发生了什么吗？您可以对applciation代码的其他部分采取相同的心理方法吗？