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

耦合的形式

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

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

• 透明耦合

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

纠正

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

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

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

个人理解

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

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

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

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

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

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