[概念] 減少耦合性

[H45 (!H45)]

耦合性 Coupling
一群類別的耦合得愈緊密，愈難了解整個系統，也愈難進行維護。如果類別之間有相依性
，那麼修改一個類別，也得修改另一個類別，才能滿足需求。但是，尋找所有需要修改的
地方是非常耗時的工作，也容易發生錯誤。而且，在另一個系統中重複使用既有的類別，
必須將其耦合的類別也涵蓋進來，否則該類別無法運作。

減少類別的耦合性可以提升系統的維護性，以下由強到弱依序列出耦合性的種類

1.      Content coupling
說明：一個類別直接修改另一個類別的內部資料。
建議：永遠避免此種耦合性。
解決：利用封裝來保護類別的內部資料。

2.      Common coupling
說明：一個類別含有全域變數，開放給所有類別存取。
建議：最大地避免此種耦合性。
解決：利用封裝來保護類別的內部資料；設置常數來防止修改；套用 Singleton Pattern
來封裝物件的全域存取；只在系統相關的類別留下全域變數。

3.      Control coupling
說明：藉由一個控制變數來決定另一個類別的行為。
建議：儘量避免此種耦合性。
解決：利用多型來決定合適的行為；建立表格來記錄控制變數與其對應之行為。

4.      Stamp coupling
說明：你所定義的類別出現在另一個類別的方法之參數串列中。
建議：有些情況下，此耦合是必要的；但是有些情況下，最好排除此種耦合性。
解決：使用介面來取代參數型態；使用基本變數（整數、浮點數、字串）來取代參數。

5.      Data coupling
說明：方法中的參數是一連串的基本變數（整數、浮點數、字串）
建議：雖然幾乎不用避免此耦合性，但是一個方法含有愈多的參數，則耦合性愈強。
解決：減少不必要的參數；在 stamp coupling 和 data coupling 之間取捨，三個或四
個參數以上不如一個介面來的簡單。

6.      Routine call coupling
說明：一個類別呼叫另一個介面所定義的方法
建議：不需要特別避免此耦合性，但是如果某一系列的方法經常伴隨出現，則耦合性愈強
。
解決：創造一個方法來封裝經常伴隨出現的方法串列。

7.      Type use coupling
說明：一個類別使用另一個類別
建議：雖然修改成員變數與方法的名稱，需要一起修改使用者呼叫的地方所使用的名稱，
但是不需要特別避免此耦合性。
解決：使用介面而非類別。

8.      Inclusion/import coupling
說明：在 Java 中 import 一個 package 或在 C++ 中 include 其他模組。
建議：雖然被 import 或 include 的類別修改之後，呼叫該類別的地方可能需要跟著修
改，避免發生新舊版本的衝突，但是不需要特別避免此耦合性。
解決：不要 import 或 include 不需要的模組；儘量只 import 或 include 標準函式庫
。

9.      External coupling
說明：一個類別依存於作業系統、共享函式庫、硬體設備。
建議：儘量減少含有依存性的程式碼
解決：套用 Façade design pattern 來提供外部設備的使用介面。

每種耦合性都舉例的話，那會是長篇大論，所以我只簡單介紹耦合性，算是給個設計的指
引。我發現 Wikipedia 所述之耦合順序與我所參考的書物有些不同，何者比較有道理就
由閱讀者自己判斷吧。

參考書物：
        Object-Oriented Software Engineering 2/e -
                Practical Software Development using UML and Java

Wikipedia:
        http://en.wikipedia.org/wiki/Coupling_(computer_science)

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 140.116.247.13
推 hilorrk     :一般來說coupling的分析非常不容易 尤其在大型專案中
→ hilorrk     :很多直覺性的寫法都會造成coupling的增加 最好的辦法
→ hilorrk     :就是在一開始規劃程式時就做好最大的切割
→ H45         :實務上，雖然一開始規劃的好好的，但是規劃總是趕不
→ H45         :上變化，變化總是趕不上老闆的計劃
推 Eventis     :老闆有計劃(謎)嗎?
推 undeadj     :應該是一通電話XD