减小耦合(bymartinfowler)

最早的设计质量的标志之一就是耦合。它在最早的结构化设计中和内聚一起出现，并且从未消失过。我在考虑软件设计时仍然总是想到它。有几种方法描述耦合，不过它可以缩减成这样:如果在一个程序中的一个模块的变化需要另一个模块的变化，那么耦合存在了。这可能是两个模块在一点做相似的事情，因此在一个模块中的代码是另一个模块中的代码的有影响的重复。这是一个代码重复的最主要和明显的罪恶的例子。重复总是意味着耦合，因为一段重复代码的改变意味着另一段代码的改变。而且也很难找出重复代码，因为可能在两段代码间没有显而易见的关系。

耦合也出现在当在一个模块中的代码使用了另外模块的代码，可能通过调用一个函数或存取一些数据。在这一点上，变得很清楚，不像重复代码，你不能总是避免耦合。你能将一个程序分成许多模块，而这些模块需要用某种方式通信—否则，你只不过是有许多程序。耦合是需要的，因为如果你禁止模块之间的耦合，你只有将所有的东西放一个大模块中。那么，将有大量的耦合—只藏在地毯下。

因此耦合是我们需要控制的东东，不过怎样控制呢？我们需要任何地方都担心有耦合吗，或是不是在一些地方有比另外一些地方重要呢？哪个因素使耦合不好，哪些是可以允许的呢？

看待依赖

我自己最关心最高层模块的耦合。如果我们将一个系统分成一打（或更少）大型模块，这些模块怎么耦合呢？我关注粗粒度的模块，因为担心任何地方的耦合会令人困惑而不知所措。最大的问题来自上层的未控制的耦合。我不担心耦合在一起的模块的数目，但是我关注模块之间依赖关系的样式。我也发现图(diagram)对我们很有帮助。

当我使用依赖这个术语，我把它作为uml中定义的那样来使用。因此如果UI(userinterface)模块中的任何代码通过调用一个函数使用一些数据，或使用了领域模块中定义的类型的方式引用了领域模型中的任何代码，那么UI模块依赖于领域模块。如果任何人改变了领域模型，UI模型将会有需要改变的可能性。依赖是单向的:UI模块通常依赖于领域模块，而不是其他情况。我们将会有第二个依赖如果领域模块也依赖于UI模块。

UML依赖也可以是不传递的。如果UI模块依赖于领域模块，并且领域模块依赖于数据模块，我们不能假设UI模块依赖于数据库模块。如果确实是依赖的，我们必须用一个额外的在UI和数据库模块的直接的依赖。这个非传递性很重要因为它让我们知道领域模型使UI绝缘了数据库中的变化。因此，如果数据库的接口变化了，我们不必马上担心UI上的变化。UI只有当数据库中的变化在领域模型产生了足够大的变化而领域接口也变化了时才变化。

图1a显示了我怎么用UML符号画这种情况。UML是为OO系统设计的，不过基本模块的符号和依赖适用于大多数软件的风格。这种高层模块的UML名字叫包(package),因此我从现在起将用这个术语(因此UML警察不会逮捕我!:P)因为这些是包，我叫这种图包图(然而在UML中严格的叫类图)。

我这里描述的是分层结构，对任何从事信息系统的人来说都是很熟悉的。一个信息系统中的层为我们描述在考虑依赖时必须的事情提供了很好的素材。对于依赖结构的最通常的建议是避免循环。循环是带来问题的，因为它们指出你会得到一个每个变化导致其他变化，而这些变化又回到了初始的包中。这样的系统更难理解因为你只有重复循环很多次。我不把避免包之间的循环作为一个严格的定律。如果它们是局部化的，我将会容忍它们。在一个应用程序的同一层的两个包之间的循环的问题更小。

一个映射器(mapper)包

在图1a中，所有的依赖都是一个方向上的。这是一个控制得很好的依赖的集合的标志，但不是需求。图1b表现了另一个信息系统的通常的特征，当一个映射器包把领域模型从数据库分开。(一个映射器是提供双向绝缘的包。)映射器包提供双向绝缘，让领域模型和数据库分别独立的变化。作为结果，你能常常在更复杂的OO模型中发现这种样式。

当然，如果你想想当你存取数据时发生了什么，你会发现这张图片不是很正确。如果领域模型中的一个模块需要从数据库得到一些数据，它怎么得到呢？它不能请求映射器，因为如果它可以，将导致从领域模型到映射器的一个依赖，从而导致循环。为了解决这个问题，我需要不同种类的依赖。

到现在为止，我已经讨论了一段代码使用其它代码的的依赖。不过有另一种依赖----接口和它的实现的关系。实现依赖于接口，反之不成立。特别是任何一个接口的调用者只依赖于接口，即使是一个分离的模块实现了它。

图2描述了这个想法。领域模型依赖于接口，而不是实现。领域模型离开了一些映射器实现不能工作，不过只有接口里面的变化会导致领域模型的变化。

在这种情况下，有一些分离的包，不过不是必需的。图3表现了领域模型中的一个存储包，由映射器中的一个存储实现来实现。在这种情况下，领域模型为映射器定义接口。简而言之就是领域包可以和任何被选择去实现存储接口的映射器工作。

定义一个分离的用于实现的一个模块的另一个模块中的接口是一个基本的打破依赖和减小耦合的方法。这种实践有很多形式，最基本的是回调(callback)在这种形势下，一个调用者被请求用一个特定的记号为一个函数提供一个引用，这个记号过一会会被调用。在java世界中的一个通常的例子是listener。因为listener是类，它们更浅白易懂，使情况更清楚明了。

另一个例子是一个模块定义了它们传出、别人可以反应的事件。你可以考虑把事件作为监听模块通常遵守的接口。回调函数的调用者，监听模块的定义者，和事件的制造者不知道哪个模块实际上被调用，因此这里没有依赖。

我觉得缺少一个结尾，因为我所说的包含如“控制的好的依赖”这样的晦涩的词。我很难提供试图去定义一个控制得好的依赖的集合的好的指南。当然，是关于减少耦合的量，不过这不是全部的事情。依赖的方向和他们指向的方式，如避免循环，也很重要。并且，我对待所有的依赖都一样，不考虑接口的宽度。有依赖比担心你依赖于什么更重要。

我所遵守的基本定律是发现我的高层依赖并弄清楚它们，分离接口与实现来打破我不希望的依赖。像很多设计的经验的研究一样，这看上去很不完善。不过我已经觉得很有帮助了----最后，我要说的结束了。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有