未来将越来越不可预测，这是新经济最具挑战性的方面之一。商务和技术上的瞬息万变会产生变化，这既可以看作要防范的威胁，也可以看作应该欢迎的机遇。

——Martin Fowler & Jim Highsmith, 《敏捷宣言》

如何应付软件开发与维护中的“变化”，一直是近年来备受软件企业关注的问题。敏捷方法的兴起，更是为“随需应变”带来了一股强劲的浪潮。

作为软件架构师，你应该对“将来的软件能在多大程度上适应新的变化”负责。同时，软件架构师又不能为了支持变化而“穷兵黩武”——即支持所有能想象得到的变化，而不管这些变化发生的几率到底有多大，也不管这样做的代价有多大。对此，Robert Martin在《敏捷软件开发》中曾告诫我们说：

对于应用程序中的每个部分都肆意地进行抽象同样不是一个好主意。正确的做法是，开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。

本章从理论和实践两方面，和大家分享笔者在敏捷设计方面的心得：

Ÿ   首先，以一种全新的角度考察耦合，并将其表述为良性依赖原则；

Ÿ   然后，通过应用实例，说明该原则如何和著名的“面向对象设计5大原则”结合，来“务实地应付变化”；

Ÿ   最后，从应付变化的角度，对各原则做综合总结。

本章是“理论联系实际”、务实运用耦合思想的范例。需要说明的是，本章采用“良性依赖原则”的叫法，是出于和依赖倒置原则（Dependency-Inversion Principle）的叫法保持一致的目的；由于“耦合”和“依赖” 是一对使用都非常广泛的同义词，所以叫做“良性耦合原则”也是可以的。

21.1.1  依赖的概念

依赖（Dependency）：两个元素之间的一种关系，其中一个元素变化，导致另一个元素变化。

依赖的同义词：耦合（Coupling），共生（Connascence）。

依赖的危害：如果被依赖元素发生变化，可能引起另一个元素不得不变化。

21.1.2  从会不会造成“实际危害”的角度考察依赖

关于依赖，已经研究得很多了：从依赖程度的大小角度来考察，有了耦合度相关理论；从依赖产生的原因角度来考察，有了静态共生性、动态共生性和差异共生性的相关理论；不一而足。

是的，如果被依赖元素发生变化，可能引起另一个元素不得不变化，这就是依赖的危害。但是，如果被依赖元素不发生变化呢？答案是：不会造成危害！于是，“冤案”产生了：由于需求分析上的偏差，设计中“在理论上”很稳定的耦合度低的依赖，可能“在实际中”恰恰是给我们造成危害的家伙；相反，“在理论上”声名狼藉的耦合度高的依赖，“在实际中”也可能并不给我们造成任何危害。

于是，我们很自然地想到，区分依赖的“实际危害”和“理论危害”是有实践意义的。下面，从会不会造成“实际危害”的角度来考察依赖，将其分为良性依赖和恶性依赖两种类型。

Ÿ   恶性依赖：被依赖的元素“在实际中”，而不是“在理论上”，是“易变的”；

Ÿ   良性依赖：被依赖的元素“在实际中”，而不是“在理论上”，是“不易变的”。