追求代碼質量: 謹防緊密耦合！

在過去一年的時間中，我在“ 追求代碼質量 ”專欄撰寫了大量的文章。這些文章向大家介紹了許多可以改進代碼質量的工具和技巧。我已經向大家展示了如何應用代碼度量來監控代碼庫的質量；如何使用 TestNG、FIT 和 Selenium 之類的測試框架來檢驗應用程序的功能；以及如何使用 XMLUnit 和 StrutsTestCase 之類的擴展框架（和一些功能強大的幫助工具，如 Cargo 和 DbUnit）來擴展測試框架的應用范圍。

雖然代碼度量和開發人員測試對于在整個開發過程中確保代碼質量非常重要（就像我經常所說的，要及時并經常進行測試），但是它們基本上只能對代碼質量做出反應。您通過測試和度量代碼來確定和量化代碼的質量，但是代碼本身都已經寫好了。不論您做出何等努力，都會受困于最初的設計。

改進代碼質量 不要錯過 Andrew 的 代碼質量討論論壇，該論壇可以幫助您解決代碼度量和測試框架方面的問題，以及如何編寫以質量為中心的代碼。

當然，不同的方法所設計出來的軟件系統會有好有壞，良莠不齊。優秀設計的關鍵因素之一就是注意保持系統的可維護性。粗劣設計的并可執行的系統可能易于編寫，但是要對它們提供支持確實是一個挑戰。這些系統往往脆弱不堪，也就是說對系統中某個區域的修改將會影響到其它看上去毫不相干的區域，因此要對它們進行重構也相當的困難和耗時。向代碼庫中添加開發人員測試可以為我們提供工作的規劃，但是其進展本身仍然是一個艱苦和緩慢的過程。

我們可以通過重構來改進已經編寫好的代碼，但是通常來說在代碼已完成之后再進行改動花費巨大。而如果在一開始就把代碼編寫得 盡善盡美 會不會更加方便和輕松呢？ 這個月，我將介紹一種非常主動的技巧，可以確保軟件系統的質量和可維護性。依賴性倒置原則 被證明是編寫可維護和可測試的高質量代碼的必要條件。依賴性倒置原則的基本思想就是對象應該依賴于抽象 而不是實現。

是依賴性倒置 而不是依賴性注入 依賴性倒置原則與依賴性注入并沒有直接的關系。依賴性注入，也被稱作控制反轉（inversion of control，IOC)，即使用 Spring 之類的框架在運行的時候（而不是在編譯的時候）鏈接對象的依賴關系。雖然依賴性倒置和依賴性注入并不需要同時使用，但是它們是互補的：兩個技巧都力爭利用抽象而不是實現。請參閱 參考資料，獲得更多有關依賴性倒置原則的知識。

過于緊密的耦合

您可能至少聽說過面向對象編程中所使用的術語耦合（coupling）。耦合即應用程序中各組件（或各對象）間的相互關系。松散耦合的應用程序要比緊密耦合的應用程序更具模塊化。松散耦合應用程序中的組件依賴于各種接口和抽象類，而緊密耦合的系統則與之相反，其組件依賴于各種具體的類。在松散耦合的系統中，其組件是使用抽象而不是 實現來相互關連的。

如果有圖解的話，可以很輕松地理解緊密耦合的問題。舉例說明，圖 1 中的軟件系統的 GUI 與它的數據庫相耦合：

GUI 對某個實現（而不是抽象）的依賴會對系統造成限制。在數據庫未啟動和運行的情況下 GUI 是無法執行的。從功能的角度上看這種設計似乎并不是很糟糕 —— 畢竟，我們一直都是這樣編寫應用程序而且也沒有出什么問題 —— 但是測試就要另當別論了。

‘脆弱’ 的系統

圖 1 中的系統使得隔離編程格外地困難，而這對測試和維護系統各個方面又十分必要。您將需要一個具有正確查找數據的活動數據庫來測試 GUI，和一個運行正常的 GUI 來測試數據訪問邏輯。您可以使用 TestNG-Abbot（現在的名稱為 FEST）來測試前端，但是這樣仍然無法告訴您任何有關數據庫功能的內容。

清單 1 展示了這種糟糕的耦合。GUI 的一個特定的按鈕定義了一個 ActionListener，它通過 getOrderStatus 調用直接與底層數據庫通信。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 代碼 謹防 耦合 質量