編寫程序前的設計與思考
1.分析業務,從業務流和業務規則中歸納出領域對象.這些對象一般放在src/com/yourname/domain下.
2.根據業務,考慮為領域對象提供完整的服務需要那些服務類.這些對象一般放在src/com/yourname/service下.
3.思考從輸入開始,到輸出結束,程序要運行正常,服務類需要那些屬性和方法,這些成員代表什么意義具有什么價值,方法的參數的返回值分別是什么.
4.思考要讓服務類為領域對象類提供完整普適的服務,領域對象類需要做怎樣的調整,需要歸納那些共同的基類.這里可以繪出領域類和服務類的靜態類圖協助思考.
5.考慮還需要那些實用類來幫助實現程序.這些對象一般放在src/com/yourname/util下.
6.在領域類和服務類的基礎上設計持久層,控制層和表現層(當前階段暫時不會接觸).
軟件設計的通用原則
Domain first:先歸納程序的領域對象,歸納出來才清楚程序要做什么.
Service second:其次歸納程序的服務對象,歸納出來才知道該怎么去做.
前兩步完成后可以說設計已經完成了大半.
Persistence the third:再次再考慮數據如何持久化到持久層中,比如說數據庫表結構的設計.
Presentation the last:最后考慮表現層的東西,比如說界面方案.
現代軟件設計的核心-類的設計
從上兩步可以看出,軟件設計其實就是類的設計工作,類設計的結果直接影響著軟件的方方面面,所謂持久層設計,表現層設計都是類設計的泛化和深化,所以說類設計直接影響著軟件的興衰成敗.
那么關于類設計的準則和評價標準是什么呢?
類設計的五條基本準則
單一職責原則(The single responsibility principle): 一個類有且只有一個中心目的,它為一個中心目的所設計,只能因為中心目的相關原因而改變.
開放-封閉原則(The open-close principle):類高度內聚,和其它類的耦合程度小,應該可以在不改變類的情況下,改變類所在的環境.
里斯科夫替換原則(The Liskov substitution principle):派生類的行為為基類所規定和限制,避免使派生類的方法非法化或者退化它們.基類的使用者不需要了解派生類就能正確的通過接口使用它們.
依賴關系倒置原則(The dependecy inversion principle):基于抽象類和接口而不是具體的類形成設計構架,因為抽象類和接口相對具體類而言更不容易被改動.
接口隔離原則(The interface segregation principle):給對象的每個使用者一個單獨的接口.其中只包含它們需要的方法,不要設計一個包含很多方法的接口讓不需要這些接口的類去實現它們.
類的評價標準-抽象相關
類是否有一個中心目的.
類的命名是否恰當,其名字是否表現了其中心目的.
類的接口是否展現了一致的抽象.
類的接口是否讓人明白的知道該如何使用它.
類的接口是否足夠抽象,是你能不必顧慮它是如何進行服務的.
類提供的服務是否足夠完整,能讓其它類無須了解動用其內部結構.
是否已經去除無關信息.
是否考慮過把類進一步分解成組件類?是否已經盡可能將其分解.
再修改類時是否維持了其接口的完整性.
類的評價標準--封裝相關
是否把類成員的可訪問性降至最小.
是否避免暴露類中的數據成員.
類是否已經盡可能的對其它類隱藏了實現細節.
類是否避免對其使用者,包括其派生類如何使用它做了假設.
類是否不依賴其它類,它是松耦合的嗎?
典型的設計的臭味
僵化性(Rigidiry):類之間耦合嚴重,系統幾乎很難改變,改變一處就不得不改動其它地方,甚至引起無休止的連鎖反應.
易碎性(Fragility):改變系統的某個部分,會破壞許多完全無關的部分.這一般由不必要的語法結構引起,如過度復雜的循環和分支.
固化性(Immobility):很難將系統分解成可供其它系統使用的組件,細化不夠會引起這樣的問題.
粘稠性(Viscosity):開發環境總是和輸入輸出和庫粘在一起.永遠走不出編輯->編譯->測試這一無休止的循環,分層不清晰會引起這樣的問題.
不必要的復雜性(Needless Complexity):很多充滿著智慧的代碼結構目前還不需要,但有一天可能會排上用場,喜歡事先考慮幽靈需求的程序員經常給代碼帶來這樣的異味.
不必要的重復(Needless Repetition): 系統充斥著重復代碼,看上去象只會VC大法(Ctrl+C,Ctrl+V)的程序員寫的,懶惰不思考是造成這個問題的根源.
不透明性(Opacity):代碼不能體現創建人的意圖.
何謂良好的設計
設計良好的系統應該容易理解,容易改變,容易重用.它實現起來沒有任何特殊的困難,簡明扼要而經濟.它不會散發出代碼臭味,公司樂于生產這樣的系統,客戶樂于使用這樣的系統,維護人員樂于維護這樣的系統.
設計良好的現代軟件特征
最小的復雜度:整個系統可以分解為簡單而易于理解的各個部分.
易于維護:程序有良好的可維護性.
松散耦合,通過應用類接口中的合理抽象,封裝性以及信息隱藏等原則,設計出相互關聯盡可能最少的類.
適應變化: 能在不改變系統基本構架的基礎上,適應未來的變化,有良好的擴展性,程序可擴展,可重用.
有明晰的層次,每層各司其職,有良好分工.
高扇入低扇出:系統很好的利用了較低層次上的工具類,重復代碼很少或沒有.
有良好的規范:無論多少人參與了項目,從代碼看來猶如出自一人之手.
使用標準技術.