关于解耦方式的思考

解耦都是须要代理的。本质上并不存在没有代理就发生两个部件之间解耦的状况。

耦合，指的是两个协做的部件的关系。
A和B发生了协做，则A和B的关系是耦合。

若是A和O,P,Q,S...(简称集合F)协做，则A就和集合F发生了耦合，若是A发生了变化，想要维持系统正常，那么集合F就须要顺应A的变化而变化，以保持协做有效。一样的，集合F中的任何一个发生了变化，A也须要发生变化（至少是局部的变化），以保持协做有效。

因此，就算A具备多种工做方式，来分别同集合F协做，它依然是同集合F耦合的。

要想让A与集合F解耦，只有经过增长一个代理（B）来实现。

---

代理B有两种方式完成本身的工做:

• 提供一套它制定的协议给A和集合F，让A和F都按B的安排来工做。（例如"USB数据线"，它告诉手机怎么传输数据，同时告诉电脑怎么接收数据，手机和电脑按照"USB数据线"的安排来工做；例如RabbitMQ）

  这种工做方式，本质上是将A与F的耦合，拆成了 A与协议B的耦合 + F与协议B的耦合。也就是将"部件和部件"的耦合拆为了"部件和协议"的耦合

• 它做为话事人，分别适配集合F的每个元素。（例如翻译软件，能够将全部语言翻译为中文；例如JVM）

  这种工做方式，本质上是将A与F的耦合，拆成了 A与B的耦合 + F与B的耦合。本质上仍是"部件和部件"的耦合，只是多了B做为A和F变化的缓冲区。

---

显然工做方式1是更为优秀的，但工做方式2有其存在的缘由。当两个已经独立存在的系统想要发生协做时，几乎只有工做方式2能站出来解决问题。好比两个语言不通的人交流；好比windows跑java，macOS跑java。当咱们架构系统的时候，应该尽量发现那些能够被工做方式1解耦的点，一旦系统开始施工，要用工做方式1解耦就会带来额外的时间和精力开销。

总结一句：架构的目标是，让一切经过协议耦合！