3

我已经向我的团队介绍了 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 类图来构建应用程序模型。我可以给出每个接口的描述，但仍然不确定它们是否明确连接。

4

2 回答 2

2

我倾向于仅在涉及关系时才考虑接口，因此我无法真正为您提供具体类型的广泛概述/类图。正如有人已经指出的那样，如果您想在图表上显示具体类型，它只会与一个特定运行的快照相关——每次对象图以不同方式连接时，它都会改变。

我认为在图表中布置接口通常更有帮助，然后浏览代码库以查找实现。使代码浏览变得非常简单的一个技巧：

获取Visual Studio 的 ReSharper 插件并使用以下快捷方式（当您的插入符号位于类/接口上时）：

Alt+ Home-- 转到基础/界面

Alt+ End-- 转到派生/类型实现接口

这两个快捷方式对于浏览具有大量松散耦合的代码库是绝对必要的。

于 2009-10-25T02:55:36.833 回答
1

UML 交互图可以显式地显示这种关系：这调用...

UML 类图可以显示该类使用该接口并且该接口由该类实现。

现在这样的图表是关于为特定执行做出的特定选择的“时间点”陈述，特定的注入可能已经发生。因此，在某种程度上，在提供图表时，您正在远离您正在使用的通常灵活的设计，但是我可以理解人们确实发现这些图片很有帮助。

我尝试考虑与接口相关的设计方面，我真的不需要了解接口描述的方法“如何”实际工作，了解实现在做什么。Onde 的想法是我们确实需要对我们的依赖项采取黑盒方法。所以我建议鼓励人们不要需要这样的图表，而是从责任的角度来思考。（这一切都很好，直到事情不起作用，然后诊断可能需要更多）但是考虑：当您使用许多操作系统和 .NET 功能时，您真的知道真正发生了什么吗？您可以对应用程序代码的其他部分采用相同的思维方式吗？

于 2009-10-24T14:47:07.773 回答