耦合的形式（對以往思路的糾正）

耦合的形式

• 不透明耦合（或者叫渾濁耦合）

  部件A直接驅動部件C，C對A不透明

• 透明耦合

  部件A驅動代理B，代理B驅動部件C，C對A透明

糾正

曾經我將耦合的形式區分爲：不透明耦合，單邊透明耦合，雙邊透明耦合。其中雙邊透明耦合的定義是，驅動方對被驅動方透明，被驅動方也對驅動方透明。這個定義存在瑕疵，被驅動方對驅動方透明這一點是合理的，但驅動方對被驅動方透明則存在邏輯缺陷。被驅動方是被使用的一方，它的存在是具備獨立性的，它並不以使用方是誰爲轉移。也就是說驅動方原本對被驅動方就是透明的，使用這一點來定義某種關係或概念，是錯誤的。因此我將雙邊透明耦合的概念剔除了。

再者，我曾經將不透明耦合的內容理解爲，驅動者直接或經過代理驅動被驅動者，這也是有問題的。問題出在，若是驅動者使用代理來驅動被驅動者，則驅動者實際上將不須要知道被驅動者的具體狀況，不管代理是哪一種工做模式（部件模式，或協議模式）。例如裝飾器模式，當使用裝飾器來作代理時，被裝飾的東西對驅動方已然透明瞭。因此當引入代理時，不透明耦合就必定會進入透明耦合形式，區別僅在於引入的代理是部件模式仍是協議模式。

綜上，新的耦合形式被定義爲不透明耦合和透明耦合兩種。

個人理解

不透明耦合（渾濁耦合）沒有什麼可多說的，主要說一說透明耦合。

透明耦合由於引入了代理，你們看我另外一篇文《關於解耦方式的思考》，代理有兩種工做模式，一種是將部件和部件的渾濁耦合解耦爲兩次部件和代理的渾濁耦合；一種是將部件和部件的渾濁耦合解耦爲兩次部件和協議的渾濁耦合。

協議是一種凌駕於真實部件之上的指導方針，抽象思想，因爲它的抽象特性，使用它去解耦相較於使用真實部件要更靈活，更能適應變化，更有益於變化點的擴展。美國各個州的州法就是在美國憲法的框架下制定的，憲法規定了各州制定州法的協議，但憲法又不去直接制定州法。國會經過憲法這個代理來管理州法。也所以各州的法律得到了至關的自由，能夠適配各州人民的不一樣性格。

以Java爲表明的一些OOP語言，支持多態技術，多態中的接口（interface）就是協議模式的代理。

最近在看許式偉老師的架構課，受益不淺。之前我對所謂的需求，很不耐煩，在我看來，一個東西就應該作成徹底模塊化的，一輛汽車就是前進後退左右拐就行了嘛，至因而什麼車，全部零件模塊化就行了嘛，想要什麼車都能用零件拼出來。在這種思想下，我作出了Fast-Converter的初版，它就是一個徹底熱插拔的東西，甚至約等於我什麼都沒作，就定義了兩個接口，它的所有特性都依賴於你如何組合模塊。許式偉老師談到了需求，他認爲需求是區分功能項中穩定點和變化點的關鍵。依賴穩定點，一個產品才顯現其價值，穩定點是須要去獨立演進，不斷增長和提升產品價值的地方。而變化點則是你須要設計擴展口的地方。看到這我才恍悟，原來穩定點是一個產品的靈魂及核心價值，設計一個徹底模塊化的東西是一條路，固化一個東西中的核心也是一條路。不少開源項目實際上是這樣作的，它們使用大量的模塊化設計，並開發核心功能，將核心功能以模塊的形式添加到系統中，這樣，不管是大衆想要用本身的想法實現核心功能，仍是它本身想要升級核心，均可以「無痛」的經過更換模塊實現。

模塊化，協議代理只是一種實現手段，它們不是產品的價值所在，你定義了一輛徹底模塊化的車，這輛車沒有價值，構成這輛車的模塊纔有價值，而構成這輛車中的由你實現的那些模塊，纔是你所完成的工做的價值所在。