打造可維護軟體C#版 第六章 不同模組之間的關注點分離

        第六章內容作者談到類別與類別之間的耦合關係，作者列出三種重構技巧降低耦合度。

指導方針：

避免形成大型模組，達成模組之間鬆散耦合。

將不同職責分配給不同模組，並且隱藏介面內部的實作細節。

鬆散耦合之程式碼基礎的變更比較容易監控及執行。

 

模組概念對應到物件導向語言類別。

 

惡例中 UserService 類別逐漸新增加功能成為龐大的類別，而且知道太多相關程式碼的細節，這個類別與其他類別產生緊密耦合。

 

耦合意味著系統的兩個部分，在變更發生時以某種方式相關聯。這種連結可能是直接呼叫，也可能透過組態檔案、資料庫結構。

 

要了解類別之間的耦合關係的重要性，你必須理解下列兩個原則：

 

耦合是原始碼類別層面的問題。

緊密或鬆散耦合基本上是程度的問題。

 

類別拆分之後，呼叫數量可能不會減少，然而耦合程度確實降低了，因為發生耦合的程式碼變少。

6.1  動機

鬆散耦合的小模組讓開發人員能夠獨立處理程式碼基礎的某個部分

鬆散耦合的小模組讓我們更容易瀏覽程式碼基礎

鬆散耦合的小模組避免讓開發新手覺得手足無措

6.2  如何使用本章指導方針？

根據不同關注點拆分類別

這招是把大的類別拆成小類別，原本的UserService 類別過大，範例程式拆分為三個類別。

將特定實作隱藏在介面背後

這招是利用介面interface隱藏實作的細節。

使用第三方程式庫/框架替換自定義程式碼

這招是使用前人已經寫好的程式來解耦合。

6.3  常見的反對意見

反對意見：鬆散耦合與程式碼重利用相衝突

程式碼重利用不應該導致緊密耦合：

良好的軟體設計例如繼承、將實作藏在介面之後，可讓程式碼重利用，又能保持鬆散耦合。

更少的程式碼，並不代表程式就會變成緊密耦合。

反對意見：C#介面不單只為了鬆散耦合

使用介面是隱藏實作而提高封裝性的好方法，但不應該位每個類別提供介面。

一個介面至少要被兩個類別實作才有實際意義。

反對意見：頻繁呼叫工具類別是不可避免

如果有某個功能真的很常用，通常都有框架或程式庫已經實作這個功能。

反對意見：不是所有的鬆散耦合都會提升可維護性

某些控制反轉IoC會增加程式碼複雜度，問題根源在於框架而不是控制反轉。