|
|
上周末，麥斯博在上海召開了亞太軟件研發團隊管理年會，我作為講師參與了架構分會場的演講。我的演講題目正是《對象設計的藝術》。“藝術”這個詞語有些大，有點玄，不過我確乎希望能將設計作為一種藝術，與工程結合，既注重實效，又能保證軟件的質量，代碼的優雅。在這次演講中，我希望能夠深層次地挖掘所謂設計的本質。這是我的有感而發。因為在設計領域中，前人已經為我們總結了太多的思想、原則與模式。這些內容汗牛充棟，很多程序員根本無法窮盡其內容。學得越多，感覺懂得越少。而如果就這樣無知下去，自然也不利于技能的提升。因此，我嘗試著去抓住設計的某些核心價值，這就是我總結出來的七種“武器”：重用、擴展、分離、變化、簡約、一致、間接。
重用
軟件開發的最大敵人就是重復。它會導致重復開發、無法有效復用以及解決方案蔓延。避免重復的方法包括：保持對象的細粒度、高內聚以及對對象的合理封裝。我們可以從方法級、類級以及模塊級提高軟件的復用性。例如，我們提取方法或類，定義輔助類，按照依賴關系劃分模塊。如下的類圖就是在JUnit Framework中利用模板方法模式實現部分邏輯的復用：
擴展
優良的軟件結構可以很好地支持擴展，而不用修改源代碼。對于擴展性而言，代表兩重含義。其一是內部的擴展，它不會在外部接口上增加新的功能，而僅僅是對對象職責的裝飾，或通過代理對象對其進行控制。其二則是外部擴展，我們可以利用繼承和組合在重用的基礎上，完成對象功能的擴展。當然，最重要的方法是利用抽象。例如，Java提供的Runnable接口，可以有效地支持多線程編程中對業務的擴展：
class MyThreadStart implements Runnable {
public void run() {
//do something
}
}
Thread controller = new Thread(new ThreadStart());
controller.start();
分離
在構建架構時，最重要的一個設計原則就是關注點分離。經典的架構模式例如分層模式與MVC模式正是關注點分離的體現。分離的關鍵元素是分離變與不變，其中的核心價值即SRP（單一職責原則）。同時，我們在分離對象之后，還要考慮它們之間的協作。下圖展示了我對分離的觀點：
變化
在軟件開發中，變化是不可避免的。在分析需求時，我們必須尋找變化點。根據我的經驗，這些功能點經常會發生變化：
1、業務規則（解決方案：規則模式）
2、算法策略（解決方案：策略模式）
3、命令請求（解決方案：命令模式）
4、硬件支持（解決方案：入口模式）
5、協議標準（解決方案：元數據）
6、數據格式（解決方案：數據封裝）
7、業務流程（解決方案：工作流定制）
8、系統配置（解決方案：元數據、數據庫）
9、界面表現（解決方案：分層模式、MVC模式）
10、外界服務（解決方案：服務外觀）
簡約
保持軟件的簡約，需要謹記兩個原則：KISS（保持軟件的簡單與易用）和YAGNI（只實現實際需要的功能，而不要想當然地添加功能）。如何才能簡化復雜的實現呢？利用封裝可以隱藏復雜的實現，利用抽象可以統一模型，從而消除功能的不同。作為一名架構師，總是希望追求完美的解決方案，這是錯誤的。許多反模式真是來源于此，例如分析癱瘓，意外的復雜度，以及貨運崇拜（在不理解的情況下使用模式）。
一致
所謂“一致”包括接口、形式、調用與解決方案的一致。接口一致，則實現就可以替換；形式一致，則可以窺一斑而知全豹；調用一致，則客戶端可以透明訪問；而一致的解決方案，則是團隊合作的基石。例如，我們可以通過使用合成模式，實現調用的一致：
間接
David Wheeler說過：“計算機科學中的大多數問題都可以通過增加一層間接性來解決。”誠哉斯言。在軟件開發中，間接可以通過委托、抽象、協作來體現。間接可以降低依賴，隱藏細節，簡化客戶端調用。許多模式都體現了間接的思想，例如門面模式、調停者模式、適配器模式、策略模式以及服務定位器模式。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
