耦合的三种形式

• 不透明耦合，

  部件A直接或通过代理B驱动部件C，部件A知道部件C的存在

• 单边透明耦合，

  部件A驱动代理B，代理B驱动部件C，部件A不知道部件C的存在，部件C知道部件A的存在

• 双边透明耦合。

  部件A驱动代理B，代理B驱动部件C，部件A、C相互不知道对方的存在

此处解释一下“驱动”这个词。
系统运作一定是有一个动力源的，同一时刻A,C两个部件协作，其中一方一定是驱动方，另一方一定是被驱动方。有人可能抬杠说，物理上力是相互的，同一时刻A,C是互为驱动方，被驱动方的。实际上可以将这个时刻分两个方向来观察，如果你站在A的角度，将A看作驱动方，那么C就是被驱动方，你求一个值F1；如果你站在C的角度看，将C看作驱动方，A看作被驱动方，你再求一个值F2。那么F1 + F2 和你用其他方法求出来的结果是一样的。

在上面对耦合的三种形式的描述中，我将部件A看作是驱动方，A是一个逻辑代号，在实际系统中，它可以代表任何实际部件。因此你可以站在任何实际部件的角度思考此部件和被它驱动的部件的耦合形式。

这三种耦合形式分别由低到高代表了两个部件耦合的松散程度。

不透明耦合是耦合程度最紧密的，它要求部件A知道部件C的存在，并直接或通过代理驱动它，部件A是动力源（这和单边透明不同，单边透明驱动部件C的动力源是代理B）。通常来说，不透明耦合预示着部件A和C最多处于职能分离状态，而时空上是紧耦合的。比如齿轮和传动轴的不透明耦合；比如在主程序中调用log4j的logger.warn()，则主程序和日志程序是不透明耦合的，虽然log4j将打印日志的职能同主程序分离了，但主程序在时间和空间上都和log4j紧密耦合着。

单边透明耦合较不透明耦合要松散，在这种形式下部件A不知道部件C的存在，但部件C知道部件A的存在，并且代理B会替代部件A来驱动部件C。往往这种形式的耦合，代理B是以工作方式1（将”部件和部件”的耦合拆为”部件和协议”的耦合）工作的。典型的例子就是AOP，切点（A）不知道切面（C）的存在，而切面（C）知道切点（A）的存在，切面（C）被框架（代理B）所驱动。由于切点对切面不透明，所以切面和切点耦合，但切点不和切面耦合。这实际上意味着，当切点发生变化时，它并不对切面的故障负责。切点也没有和框架达成协议，所以对切点来说，框架和切面都是透明的。故叫单边透明耦合。

双边透明耦合是耦合程度最松散的，在这种形式下，部件A不需要知道部件C的存在，部件C也不需要知道部件A的存在，代理B替代部件A驱动部件C。同样，代理B是工作方式1。典型例子，Vue、React、Angular的双向数据绑定，输入框操作一个变量，文本框根据这个变量改变内容，输入框不知道文本框的存在，文本框也不知道输入框的存在，双方通过框架（代理B）协作。还有RabbitMQ，消息生产者不知道消息消费者的存在，消息消费者不知道消息生产者的存在，双方通过交换机（代理B）协作。

单边透明耦合和双边透明耦合都使得部件A和部件C是在职能上分离的，时空上隔离的。单边透明耦合优于不透明耦合的地方在于，它将被驱动方从驱动方中隔离出去，被驱动方不会对驱动方产生任何影响（如果有影响，则这个影响属于驱动关系调换后的场景，本质上是从另一个角度思考的结果）。双边透明耦合强大的地方在于，协作双方存在数量是任意的（包括存在与否），协作双方的协作机制是任意的，所以它是目前我所知道的，耦合程度最低的一种协作形式。

总结：三种耦合形式，有其存在的必要性，但追求松散耦合的系统应尽可能的在三种耦合形式中向后选择