耦合的形式（对以往思路的纠正）

耦合的形式

• 不透明耦合（或者叫浑浊耦合）

  部件A直接驱动部件C，C对A不透明

• 透明耦合

  部件A驱动代理B，代理B驱动部件C，C对A透明

纠正

曾经我将耦合的形式区分为：不透明耦合，单边透明耦合，双边透明耦合。其中双边透明耦合的定义是，驱动方对被驱动方透明，被驱动方也对驱动方透明。这个定义存在瑕疵，被驱动方对驱动方透明这一点是合理的，但驱动方对被驱动方透明则存在逻辑缺陷。被驱动方是被使用的一方，它的存在是具有独立性的，它并不以使用方是谁为转移。也就是说驱动方本来对被驱动方就是透明的，使用这一点来定义某种关系或概念，是错误的。所以我将双边透明耦合的概念剔除了。

再者，我曾经将不透明耦合的内容理解为，驱动者直接或通过代理驱动被驱动者，这也是有问题的。问题出在，如果驱动者使用代理来驱动被驱动者，则驱动者实际上将不需要知道被驱动者的具体情况，无论代理是哪种工作模式（部件模式，或协议模式）。例如装饰器模式，当使用装饰器来做代理时，被装饰的东西对驱动方已然透明了。所以当引入代理时，不透明耦合就一定会进入透明耦合形式，区别仅在于引入的代理是部件模式还是协议模式。

综上，新的耦合形式被定义为不透明耦合和透明耦合两种。

我的理解

不透明耦合（浑浊耦合）没有什么可多说的，主要说一说透明耦合。

透明耦合因为引入了代理，大家看我另一篇文《关于解耦方式的思考》，代理有两种工作模式，一种是将部件和部件的浑浊耦合解耦为两次部件和代理的浑浊耦合；一种是将部件和部件的浑浊耦合解耦为两次部件和协议的浑浊耦合。

协议是一种凌驾于真实部件之上的指导方针，抽象思想，由于它的抽象特性，使用它去解耦相较于使用真实部件要更灵活，更能适应变化，更有益于变化点的扩展。美国各个州的州法就是在美国宪法的框架下制定的，宪法规定了各州制定州法的协议，但宪法又不去直接制定州法。国会通过宪法这个代理来管理州法。也因此各州的法律获得了相当的自由，可以适配各州人民的不同性格。

以Java为代表的一些OOP语言，支持多态技术，多态中的接口（interface）就是协议模式的代理。

最近在看许式伟老师的架构课，受益匪浅。以前我对所谓的需求，很不耐烦，在我看来，一个东西就应该做成完全模块化的，一辆汽车就是前进后退左右拐就好了嘛，至于是什么车，所有零件模块化就好了嘛，想要什么车都能用零件拼出来。在这种思想下，我做出了Fast-Converter的第一版，它就是一个完全热插拔的东西，甚至约等于我什么都没做，就定义了两个接口，它的全部特性都依赖于你如何组合模块。许式伟老师谈到了需求，他认为需求是区分功能项中稳定点和变化点的关键。依赖稳定点，一个产品才显现其价值，稳定点是需要去独立演进，不断增加和提高产品价值的地方。而变化点则是你需要设计扩展口的地方。看到这我才恍悟，原来稳定点是一个产品的灵魂及核心价值，设计一个完全模块化的东西是一条路，固化一个东西中的核心也是一条路。很多开源项目其实是这样做的，它们使用大量的模块化设计，并开发核心功能，将核心功能以模块的形式添加到系统中，这样，无论是大众想要用自己的想法实现核心功能，还是它自己想要升级核心，都可以“无痛”的通过更换模块实现。

模块化，协议代理只是一种实现手段，它们不是产品的价值所在，你定义了一辆完全模块化的车，这辆车没有价值，构成这辆车的模块才有价值，而构成这辆车中的由你实现的那些模块，才是你所完成的工作的价值所在。