我是否应该更关注包装之间或配送单位之间的耦合？

Question

我一直关注耦合的指标请查看 DSM 。

我一直使用的工具之一着眼于“模块”之间的耦合，模块是一个分发单元（在本例中是.net程序集）。

我觉得我对查看包（或命名空间）之间的耦合比对分发单元更感兴趣。

我是否应该更关心包/命名空间之间的耦合（确保抽象只依赖于抽象，具体类型取决于抽象，它们在依赖关系中没有循环，因此重构和扩展很容易）或者我应该关注我是否可以部署新版本而无需更新未更改的分发单元？

其他人测量的是什么？

对于它的价值，我的直觉是，如果我专注于包/命名空间耦合，那么分配耦合的单位将免费或至少更容易。

Answer 1

首先，很容易过度关注依赖关系和耦合。确保你没有过度复杂化。

有了免责声明，这就是我的建议。

依赖/耦合管理实际上有三种不同的视图： 1）物理结构（即装配依赖性） 2）逻辑结构（即名称空间依赖关系） 3）实现结构（即类依赖性）

对于大型应用程序，您至少需要检查所有3个应用程序，但通常可以优先考虑。

对于客户端部署的应用程序，数字1可能非常重要（例如插件等）。对于在企业内部部署的应用程序（即asp.net），项目＃1通常证明并不那么重要（不包括在多个应用程序中重用的框架）。您通常可以轻松地部署整个应用程序，而不会为＃1带来复杂结构的开销。

项目＃2往往更像是一个可维护性问题。了解您的图层边界及其与命名空间的关系（即，您是在每个命名空间中执行1个图层，还是在逻辑级别进行不同的打包）。有时，工具可以通过查看逻辑依赖关系结构来帮助您强制执行层边界。

第3项实际上是关于做好班级设计。每个优秀的开发人员都应该付出相当大的努力来确保他只在他的班级中接受适当的依赖。这说起来容易做起来难，并且通常是一种必须随着时间的推移而获得的技能。

为了更接近问题的核心，第1项实际上是关于如何在VS解决方案中布置项目。所以这不是一个可衡量的项目。它更多的是你在开始时设置并运行的东西。项目＃2是您可以使用工具在构建期间检查以查看开发人员是否违反任何规则。它更像是一种检查，而不是一种真正的衡量标准。第3项实际上是你想要仔细研究测量的。在代码库中查找具有大量耦合的类将成为未来的难点，确保这些人的质量。此外，通过此级别的测量，您可以深入了解代码库的质量（整体）。此外，如果有人在你的代码库中检查一些非常粗糙的代码，它会给你一个红旗。

因此，如果您想优先考虑，请快速查看＃1和＃2。知道它们应该是什么样子。但是对于大多数应用程序，第3项应该占用大部分时间。

当然，这个答案排除了巨大的框架（如.NET BCL）。那些宝宝需要非常小心地注意＃1。 ： - ）

否则，你最终会遇到这样的问题： “当前版本的.NET Framework包括各种基于GUI的库，这些库在Server Core中无法正常工作”。 http://www.winsupersite.com/showcase/win2008_ntk.asp

您无法在无GUI的Windows Server 2008上运行.NET，因为该框架依赖于GUI库...

最后一件事。确保您熟悉良好依赖/耦合管理背后的原则。你可以在这里找到一个很好的清单：

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

Answer 2

分布单元之间的耦合和依赖循环更“致命”。因为它可能使部署程序变得非常困难 - 有时它甚至可能使编译程序变得非常困难。

你大多是正确的，一个很好的顶级设计，将代码划分为逻辑包，清晰和预定义的依赖关系只会让你大部分时间，唯一缺少的是将包正确分离成分布单元。