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

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

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