輕鬆編程: 通過理順軟體的依賴關係提高應用程式靈活性

本文討論:

緊密耦合體繫結構的錯誤之處

測試和依賴關係災難

依賴關係反轉

依賴關係注入

本文使用了以下技術:

.NET Framework

幾乎所有人都認為追求松 散耦合設計不是明智之舉。遺憾地是，我們所設計軟體的緊密耦合程度通常都遠遠超過我們的預期。如何 瞭解設計是否耦合緊密？可使用靜態分析工具（如 Ndepend）來分析依賴關係，但瞭解應用程式中耦合程 度最輕鬆的辦法是嘗試獨立地執行個體化一個類。

從業務層中選取一個類（如 InvoiceService），然後將其代碼複製到一個新的控制台項目中。嘗試對 它進行編譯。您很可能會丟失某些依賴關係（如 Invoice、InvoiceValidator 等等）。將這些類複製到 此控制台項目並重試。您又會發現缺少其他類。最終可執行編譯時間，您可能會發現新項目中已存在絕大部 分基本代碼。就像拉動毛線衫的一個鬆動線頭就可以拆掉整件衣服一樣。在您的設計中，每個類都直接或 間接地與其他類別結合程度。更改此類系統的確非常困難，因為任何一個類中的更改都可能牽連到系統的其餘部 分。

解決這個問題的要點不是完全避開耦合，因為那是不可能的。例如：

string name = "James Kovacs";

我已將My Code耦合到 Microsoft® .NET Framework 中的 System.String 類。這不妥帖嗎？我不這樣認為。System.String 類意外發生更改的可能性非常低，也少 有可能因要求改變而必須修改我與 System.String 互動的方式。因此我對該耦合相當放心。此樣本的用 意在於指出並非一味地消除耦合，而是要瞭解它並確保明智地選用耦合。

以經常出現在許多應用 程式資料層中的另一代碼為例：

SqlConnection conn = new SqlConnection(connectionString);

或者以下代碼：

XmlDocument settings = new XmlDocument();settings.Load("Settings.xml");

對於資料層將僅與 SQL Server® 互動或者始 終從名為 Settings.xml 的 XML 文檔中載入應用程式設定而言，您有多大把握？我們的目的不是構建一 個可無限擴充但極其複雜、無法使用的泛型架構。而是與可逆性相關。您能輕鬆地改變設計決策嗎？您的 應用程式體繫結構能否很好地響應變化？

為何我如此關注變化？因為就是這個行業中唯一不變的 就是變化。需求、技術、開發人員以及業務都在變化。您有無做好應變準備？通過建立鬆散耦合設計，軟 件就可更好地響應許多時候無法預計的必然變化。