V
VRGL
Unregistered / Unconfirmed
GUEST, unregistred user!
减小耦合
martin fowler
最早的设计质量的标志之一就是耦合,它和内聚一起在最早的结构化设计中出现，并且
从未消失过。我在考虑软件设计时仍然总是想到它。
有几种方法描述耦合，不过它可以缩减成这样:如果在一个程序中的一个模块的改变需
要另一个模块的改变，那么就存在耦合。这可能是两个模块在某个位置做相似的事情，
因此在一个模块中的代码实际上是另一个模块中的代码的重复。这是代码重复的最主要
和明显的弊病的一个例子。重复总是意味着耦合，因为一段代码的改变意味着需要改变
另一段相应重复代码。而且也很难找出重复代码，因为可能在两段代码间没有显而易见
的关系。
耦合也出现在以下情况:一个模块中的代码可能通过调用一个函数或存取一些数据的方式
使用了另外模块的代码。这时，情况变得很清楚，不像重复代码那样，你不能总是避
免耦合。你能将一个程序分成许多模块，而这些模块需要用某种方式通信—---否则，你
只不过是写了多个程序而已。耦合是需要的，因为如果你想禁止模块之间的耦合，你只有将
所有的东西放在一个大模块中。那么，将有大量的耦合产生—---只是都隐藏在表面之下。
因此耦合是我们需要控制的东西，不过怎样控制呢？我们需要在任何地方都担心有耦合
吗，或是不是在一些地方有耦合比另外一些地方有耦合更重要呢？哪些因素使耦合非常有害
，哪些是可以允许的呢？
看待依赖
我自己最关心最高层模块的耦合。如果我们将一个系统分成一打
（或更少）大型模块，这些模块怎么耦合呢？我只关注粗粒度的模
块间的耦合，因为担心任何地方的耦合会令人困惑而不知所措。最大的问
题来自顶层的未控制的耦合。我不担心耦合在一起的模块的数目，
但是我关注模块之间依赖关系的样式。我也发现图(diagram)对
我们很有帮助。
当我使用依赖这个术语，我把它作为uml中定义的那样来使用。
因此如果UI(user interface)模块中的任何代码通过调用一个函数、
使用一些数据，或使用了领域模块中定义的类型的方式引用了领域
模块中的任何代码，那么UI模块依赖于领域模块。如果任何人改变
了领域模块，UI模块将可能需要改变。依赖是单向的:通常是UI
模块依赖于领域模块，而不是相反情况；如果领域模块也依赖于UI模块，
则是第二个依赖。
UML依赖也可以不是传递性的。如果UI模块依赖于
领域模块，并且领域模块依赖于数据库模块，我们不能假设UI模块
依赖于数据库模块。如果确实是依赖的，我们必须用一个额外的在
UI和数据库模块之间的直接的依赖。这个非传递性很重要，因为它让我们
知道领域模块使UI与数据库中的变化绝缘。因此，如果数据库的
接口变化了，我们不必马上担心UI上的变化。只有当数据库中的
变化在领域模块中产生了足够大的变化而造成领域接口也变化了时，UI才变化。
图1a显示了我怎么用UML符号描绘这种情况。UML是为OO系统设计的，
不过基本模块的符号和依赖适用于大多数软件的风格。上述高层
模块的UML名字叫包(package),因此我从现在起将用这个术语(因此
UML警察不会逮捕我!)因为这些是包，我称这种图为“包图”(然而在UML
中严格的称为类图)。
我这里描述的是分层结构，对任何从事信息系统的人来说都是很熟悉的。
一个信息系统中的层为我们描述在考虑依赖时必须做的事情提供了很好的
素材。对于依赖结构的最通常的建议是避免循环。循环是会带来问题的，
因为它们意味着你会处于这样一种情况下:每个包的变化又导致其他包的变化，而这些变
化又传回到了初始的包中。这样的系统更难于理解，因为你只有重复循环很多次才能解
决问题。我不把避免包之间的循环作为一个严格的规定，如果它们是局部化的，
我将会容忍它们。在一个应用程序的同一层的两个包之间的循环的问题更小。
一个映射器(mapper)包
在图1a中，所有的依赖都是一个方向上的。这是一个控制得很好的依赖集合
的标志，但不是必须的。图1b表现了另一个信息系统的通常的特征，当一个映射
器包把领域模块与数据库分开。(一个映射器是提供双向绝缘的包。)映射器
包提供双向绝缘，让领域模块和数据库分别独立的变化。结果是，你能常常
在更复杂的OO模型中发现这种样式。
当然，如果你想一想当你存取数据时发生了什么，你会发现这张图片不是很正
确。如果领域模块中的一个小模块需要从数据库得到一些数据，它怎么得到呢？
它不能请求映射器，因为如果它请求映射器，将导致从领域模块到映射器的一个依
赖，从而导致循环。为了解决这个问题，我需要不同种类的依赖。
到现在为止，我已经讨论了一段代码使用其它代码的的依赖。不过有另一种
依赖----接口和它的实现的关系。实现依赖于接口，反之不成立。特别是任
何一个接口的调用者只依赖于接口，即使是一个分离的模块实现了它。
图2描述了这个想法。领域模块依赖于接口，而不是依赖于实现。领域模块离开了
一些映射器的实现则不能工作，不过只有接口里面的变化会导致领域模块的变化。
在这种情况下，有一些分离的包，不过这种情况不是必需的。图3表现了领域模块中
的一个存储包，由映射器中的一个存储实现来实现。在这种情况下，领域模
块为映射器定义接口。简而言之就是领域模块可以和任何被选择去实现存储
接口的映射器一起工作。
定义一个模块中的接口(该接口被另一个分离的模块所实现)是一个
打破依赖和减小耦合的基本方法。这种方法有很多形式，最基本的形式是回调(call
back)，即为了向一个函数提供一个引用，用一个特定的记号请求一个调用者，
这个记号晚些时候会被调用。在java世界中的一个通常的例子是
listener。因为listener是类，它们更浅显易懂，使事情更清楚明了。
另一个例子是一个模块定义了它们传出的并且别人可以反应的事件。你可以考
虑把事件作为监听模块通常遵守的接口。回调函数的调用者，监听模块的
定义者，和事件的制造者不知道哪个模块实际上被调用，因此这里没有
依赖。
我觉得我说的并不完备，因为我所说的包含如“控制得好的依赖”这样
的晦涩的词。我很难提供去试图定义一个“控制得好的依赖集合”的
具体的指导。当然，这是关于减少耦合的量，不过不是全部的事情。
依赖的方向和他们指向的方式，如避免大循环，也很重要。还有，我对
待所有的依赖都一样，不考虑接口的宽度。有没有依赖比你担心依赖于什
么更重要。
我所遵守的基本原则是发现高层依赖并弄清楚它们，用分离接口与
实现的办法来打破我不希望的依赖。像很多对设计的经验的研究一样，这看上
去很不完善。不过我已经觉得很有裨益了----并且最后，这是本文的价值所在。
图片1(a): http://album.chinaren.com/album/34/61685.jpg
图片1(b): http://album.chinaren.com/album/34/61687.jpg
图片2: http://album.chinaren.com/album/34/61689.jpg
图片3: http://album.chinaren.com/album/34/61690.jpg
martin fowler
最早的设计质量的标志之一就是耦合,它和内聚一起在最早的结构化设计中出现，并且
从未消失过。我在考虑软件设计时仍然总是想到它。
有几种方法描述耦合，不过它可以缩减成这样:如果在一个程序中的一个模块的改变需
要另一个模块的改变，那么就存在耦合。这可能是两个模块在某个位置做相似的事情，
因此在一个模块中的代码实际上是另一个模块中的代码的重复。这是代码重复的最主要
和明显的弊病的一个例子。重复总是意味着耦合，因为一段代码的改变意味着需要改变
另一段相应重复代码。而且也很难找出重复代码，因为可能在两段代码间没有显而易见
的关系。
耦合也出现在以下情况:一个模块中的代码可能通过调用一个函数或存取一些数据的方式
使用了另外模块的代码。这时，情况变得很清楚，不像重复代码那样，你不能总是避
免耦合。你能将一个程序分成许多模块，而这些模块需要用某种方式通信—---否则，你
只不过是写了多个程序而已。耦合是需要的，因为如果你想禁止模块之间的耦合，你只有将
所有的东西放在一个大模块中。那么，将有大量的耦合产生—---只是都隐藏在表面之下。
因此耦合是我们需要控制的东西，不过怎样控制呢？我们需要在任何地方都担心有耦合
吗，或是不是在一些地方有耦合比另外一些地方有耦合更重要呢？哪些因素使耦合非常有害
，哪些是可以允许的呢？
看待依赖
我自己最关心最高层模块的耦合。如果我们将一个系统分成一打
（或更少）大型模块，这些模块怎么耦合呢？我只关注粗粒度的模
块间的耦合，因为担心任何地方的耦合会令人困惑而不知所措。最大的问
题来自顶层的未控制的耦合。我不担心耦合在一起的模块的数目，
但是我关注模块之间依赖关系的样式。我也发现图(diagram)对
我们很有帮助。
当我使用依赖这个术语，我把它作为uml中定义的那样来使用。
因此如果UI(user interface)模块中的任何代码通过调用一个函数、
使用一些数据，或使用了领域模块中定义的类型的方式引用了领域
模块中的任何代码，那么UI模块依赖于领域模块。如果任何人改变
了领域模块，UI模块将可能需要改变。依赖是单向的:通常是UI
模块依赖于领域模块，而不是相反情况；如果领域模块也依赖于UI模块，
则是第二个依赖。
UML依赖也可以不是传递性的。如果UI模块依赖于
领域模块，并且领域模块依赖于数据库模块，我们不能假设UI模块
依赖于数据库模块。如果确实是依赖的，我们必须用一个额外的在
UI和数据库模块之间的直接的依赖。这个非传递性很重要，因为它让我们
知道领域模块使UI与数据库中的变化绝缘。因此，如果数据库的
接口变化了，我们不必马上担心UI上的变化。只有当数据库中的
变化在领域模块中产生了足够大的变化而造成领域接口也变化了时，UI才变化。
图1a显示了我怎么用UML符号描绘这种情况。UML是为OO系统设计的，
不过基本模块的符号和依赖适用于大多数软件的风格。上述高层
模块的UML名字叫包(package),因此我从现在起将用这个术语(因此
UML警察不会逮捕我!)因为这些是包，我称这种图为“包图”(然而在UML
中严格的称为类图)。
我这里描述的是分层结构，对任何从事信息系统的人来说都是很熟悉的。
一个信息系统中的层为我们描述在考虑依赖时必须做的事情提供了很好的
素材。对于依赖结构的最通常的建议是避免循环。循环是会带来问题的，
因为它们意味着你会处于这样一种情况下:每个包的变化又导致其他包的变化，而这些变
化又传回到了初始的包中。这样的系统更难于理解，因为你只有重复循环很多次才能解
决问题。我不把避免包之间的循环作为一个严格的规定，如果它们是局部化的，
我将会容忍它们。在一个应用程序的同一层的两个包之间的循环的问题更小。
一个映射器(mapper)包
在图1a中，所有的依赖都是一个方向上的。这是一个控制得很好的依赖集合
的标志，但不是必须的。图1b表现了另一个信息系统的通常的特征，当一个映射
器包把领域模块与数据库分开。(一个映射器是提供双向绝缘的包。)映射器
包提供双向绝缘，让领域模块和数据库分别独立的变化。结果是，你能常常
在更复杂的OO模型中发现这种样式。
当然，如果你想一想当你存取数据时发生了什么，你会发现这张图片不是很正
确。如果领域模块中的一个小模块需要从数据库得到一些数据，它怎么得到呢？
它不能请求映射器，因为如果它请求映射器，将导致从领域模块到映射器的一个依
赖，从而导致循环。为了解决这个问题，我需要不同种类的依赖。
到现在为止，我已经讨论了一段代码使用其它代码的的依赖。不过有另一种
依赖----接口和它的实现的关系。实现依赖于接口，反之不成立。特别是任
何一个接口的调用者只依赖于接口，即使是一个分离的模块实现了它。
图2描述了这个想法。领域模块依赖于接口，而不是依赖于实现。领域模块离开了
一些映射器的实现则不能工作，不过只有接口里面的变化会导致领域模块的变化。
在这种情况下，有一些分离的包，不过这种情况不是必需的。图3表现了领域模块中
的一个存储包，由映射器中的一个存储实现来实现。在这种情况下，领域模
块为映射器定义接口。简而言之就是领域模块可以和任何被选择去实现存储
接口的映射器一起工作。
定义一个模块中的接口(该接口被另一个分离的模块所实现)是一个
打破依赖和减小耦合的基本方法。这种方法有很多形式，最基本的形式是回调(call
back)，即为了向一个函数提供一个引用，用一个特定的记号请求一个调用者，
这个记号晚些时候会被调用。在java世界中的一个通常的例子是
listener。因为listener是类，它们更浅显易懂，使事情更清楚明了。
另一个例子是一个模块定义了它们传出的并且别人可以反应的事件。你可以考
虑把事件作为监听模块通常遵守的接口。回调函数的调用者，监听模块的
定义者，和事件的制造者不知道哪个模块实际上被调用，因此这里没有
依赖。
我觉得我说的并不完备，因为我所说的包含如“控制得好的依赖”这样
的晦涩的词。我很难提供去试图定义一个“控制得好的依赖集合”的
具体的指导。当然，这是关于减少耦合的量，不过不是全部的事情。
依赖的方向和他们指向的方式，如避免大循环，也很重要。还有，我对
待所有的依赖都一样，不考虑接口的宽度。有没有依赖比你担心依赖于什
么更重要。
我所遵守的基本原则是发现高层依赖并弄清楚它们，用分离接口与
实现的办法来打破我不希望的依赖。像很多对设计的经验的研究一样，这看上
去很不完善。不过我已经觉得很有裨益了----并且最后，这是本文的价值所在。
图片1(a): http://album.chinaren.com/album/34/61685.jpg
图片1(b): http://album.chinaren.com/album/34/61687.jpg
图片2: http://album.chinaren.com/album/34/61689.jpg
图片3: http://album.chinaren.com/album/34/61690.jpg
]