維基百科

鬆耦合

在電腦運算和系統設計中，鬆耦合的系統是指：

  1. 組件之間的關聯性不強（彼此之間的關係可以切斷），若有鬆耦合的話，會使得一個組件的變更對其他組件的影響降到最低。
  2. 每一個組件對其他獨立組件的定義所知甚少或一無所知。子範圍包括類、介面、資料和服務之間的耦合。[1]。

鬆耦合是緊耦合的對立面。

優點和缺點

編輯

鬆耦合系統中的組件可以用提供相同服務的替代實現所替換。鬆耦合系統中的組件比較不會限制使用相同平台、相同語言、相同作業系統或相同構建環境。

如果系統在時間上是解耦的，那麼也很難提供事務完整性（transactional integrity）；需要額外的協調協定。跨系統資料複製（英語：Replication (computing)）滿足了鬆耦合性（可用性），但是在維護一致性（英語：Data_consistency）（資料同步）上會出現問題。

整合

編輯

鬆耦合在更廣泛的分散式系統設計中是透過使用事務，訊息導向中介軟體（英語：Message-oriented_middleware）提供的佇列和互操作性標準來達成的。[2]

促進鬆耦合的四類自主性是：參照自主性，時間自主性，格式自主性和平台自主性。[3]

鬆耦合是一種架構原則，設計目標是面向服務架構；以下列出了鬆耦合和對應的緊耦合的11種形式：[4]

  • 透過中介的物理連接，
  • 非同步通訊方式，
  • 只在資料模型中的簡單常見類型，
  • 弱型別系統，
  • 以資料為中心並且自包含的訊息，
  • 過程邏輯的分散式控制，
  • （服務的消費者和提供者的）動態繫結（英語：Dynamic binding (computing)），
  • 平台獨立性，
  • 業務級補償而不是系統級的事務，
  • 不同的時間的部署，
  • 版本中的隱式升級。

企業服務匯流排(Enterprise Service Bus,ESB)中介軟體誕生在實現鬆散耦合的多個維度；然而，過於機械化和錯誤安置的ESB還可以產生相反的效果，產生非預期的緊耦合和中心架構熱點。[5]

事件驅動架構（英語：Event-driven architecture）也旨在促進鬆散耦合。[6]

降低耦合的方法

編輯

介面的鬆耦合可以透過發布標準格式的資料（如XML或JSON）來增強。

程式組件之間的鬆耦合可以透過使用標準資料類型參數來增強。傳遞自訂資料類型或對象需要組件雙方了解自訂資料的定義。

服務的鬆耦合可以透過減少給服務傳入的關鍵資料的資訊來增強。例如，當只有客戶標識傳入並且客戶位址在服務內取得，服務傳送一個字母是最可重用的。這將解耦服務，因為服務不需要按特定的順序呼叫（如：GetCustomerAddress，SendLetter）

編程

編輯

耦合是指一個組件直接了解其他組件的程度。運算中的鬆耦合解釋為封裝與無封裝。

緊耦合的一個例子發生在依賴類直接包含一個提供所需行為的具體類的指標。在不改變依賴類的情況下，無法替換依賴，或改變「簽章」。鬆耦合發生在依賴類只包含介面的指標，介面可以由一個或多個具體類實現。依賴類只依賴介面指定的「契約」：實現類必須提供的方法和/或屬性的定義列表。任何實現了介面的類就可以滿足依賴類的依賴而無需修改類。這使得軟體設計具有可延伸性；無需改變依賴類，可以編寫一個新類實現介面來取代當前的依賴在部分或全部的情況下；新老類可以自由交換。強耦合不允許這樣做。

這個UML圖說明依賴類和一組提供所需行為的具體類之間的鬆耦合的例子：

 

相比之下,這個圖表顯示了強的替代設計相關類之間的耦合和提供者:

 

鬆耦合的其他形式

編輯

擁有作為核心模組的函式（參見函數式程式設計）或函式對象的電腦程式語言提供了鬆耦合編程的極好的例子。函數式語言擁有續體、閉包或生成器等模式。函數式程式設計語言的例子參見Clojure和Lisp。Smalltalk和Ruby等物件導向的語言擁有代碼塊，而Eiffel擁有agent。基本思想是具象化(封裝為對象)獨立於任何其他封閉概念的函式(例如將對象函式與封閉對象的任何直接知識解耦)。作為頭等函式的一種形式，函式作為對象的更進一步知識參見頭等函式。

例如，在物件導向的語言中，當對象的一個函式被參照為一個對象（無需了解包含他的宿主對象）時，新的函式對象可以傳遞，儲存，稍後呼叫。（功能對象交給的）接收對象可以在自己方便的時候安全地執行(呼叫)所包含的函式，無需了解包含他的宿主對象。透過這種方式，一個程式可以執行功能對象的鏈或組，而安全地脫離擁有任何包含他們的宿主對象的直接參照。

電話號碼是一個極好的類比，很容易說明這種分離的程度。

例如：一些實體為他人提供電話號碼來完成一個特定的工作。當號碼被呼叫時，呼叫者實體實際上說,「請幫我做這項工作。」解耦或鬆耦合是顯而易見的。拿到號碼的實體呼叫時可能並不了解號碼從哪兒來的(例如號碼提供者的參照)。另一方面，呼叫者和被呼叫者之間解耦了，無需知道他們是誰，他們在哪裡，呼叫接收者內部是如何操作的。

將例子更進一步，呼叫者可能會對接收者說「請為我做這個工作。幹完了用這個號碼打電話回覆我。」提供給接收者的「號碼」稱為「回呼」。同樣,這個函式對象的鬆耦合或分離性質是明顯的。回呼的接收者不知道呼叫的是誰。只知道它可以呼叫，並決定何時呼叫。在現實中，回呼的可能都不是最初的提供者。這種級別的間接使函式對象成為實現鬆耦合程式的一個優秀技術。

衡量資料元素耦合

編輯

鬆耦合的程度可以透過記錄傳送或接收系統中可能發生的資料元素的變化數量來度量，並確定電腦是否仍然能夠正確地進行通訊。這些變化包括的專案如：

  1. 添加新的資料元素到訊息
  2. 改變資料元素的順序
  3. 改變資料元素的名稱
  4. 改變資料元素的結構
  5. 省略資料元素

參閱

編輯

參考資料

編輯
  1. ^ Loosely Coupled: The Missing Pieces of Web Services by Doug Kaye
  2. ^ Pautasso C., Wilde E., Why is the Web Loosely Coupled? （頁面存檔備份，存於網際網路檔案館）, Proc. of WWW 2009
  3. ^ F. Leymann Loose Coupling and Architectural Implications （頁面存檔備份，存於網際網路檔案館）, ESOCC 2016 keynote
  4. ^ N. Josuttis, SOA in Practice. O'Reilly, 2007, ISBN 978-0-596-52955-0.
  5. ^ M. Keen et al, Patterns: Implementing an SOA using an Enterprise Service Bus （頁面存檔備份，存於網際網路檔案館）, IBM, 2004
  6. ^ How EDA extends SOA and why it is important （頁面存檔備份，存於網際網路檔案館） Jack van Hoof
取自「https://zh.wikipedia.org/w/index.php?title=松耦合&oldid=80498616」