關於解耦方式的思考

解耦都是須要代理的。本質上並不存在沒有代理就發生兩個部件之間解耦的狀況。

耦合，指的是兩個協做的部件的關係。
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解耦就會帶來額外的時間和精力開銷。

總結一句：架構的目標是，讓一切經過協議耦合！