編寫程式前的設計與思考
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 inte***ce segregation principle):給物件的每個使用者乙個單獨的介面.其中只包含它們需要的方法,不要設計乙個包含很多方法的介面讓不需要這些介面的類去實現它們.
類的評價標準-抽象相關
類是否有乙個中心目的.
類的命名是否恰當,其名字是否表現了其中心目的.
類的介面是否展現了一致的抽象.
類的介面是否讓人明白的知道該如何使用它.
類的介面是否足夠抽象,是你能不必顧慮它是如何進行服務的.
類提供的服務是否足夠完整,能讓其它類無須了解動用其內部結構.
是否已經去除無關資訊.
是否考慮過把類進一步分解成元件類?是否已經盡可能將其分解.
再修改類時是否維持了其介面的完整性.
類的評價標準--封裝相關
是否把類成員的可訪問性降至最小.
是否避免暴露類中的資料成員.
類是否已經盡可能的對其它類隱藏了實現細節.
類是否避免對其使用者,包括其派生類如何使用它做了假設.
類是否不依賴其它類,它是松耦合的嗎?
典型的設計的臭味
僵化性(rigidiry):類之間耦合嚴重,系統幾乎很難改變,改變一處就不得不改動其它地方,甚至引起無休止的連鎖反應.
易碎性(fragility):改變系統的某個部分,會破壞許多完全無關的部分.這一般由不必要的語法結構引起,如過度複雜的迴圈和分支.
固化性(immobility):很難將系統分解成可供其它系統使用的元件,細化不夠會引起這樣的問題.
粘稠性(viscosity):開發環境總是和輸入輸出和庫粘在一起.永遠走不出編輯->編譯->測試這一無休止的迴圈,分層不清晰會引起這樣的問題.
不必要的複雜性(needless complexity):很多充滿著智慧型的**結構目前還不需要,但有一天可能會排上用場,喜歡事先考慮幽靈需求的程式設計師經常給**帶來這樣的異味.
不必要的重複(needless repetition): 系統充斥著重複**,看上去象只會vc**(ctrl+c,ctrl+v)的程式設計師寫的,懶惰不思考是造成這個問題的根源.
不透明性(opacity):**不能體現建立人的意圖.
何謂良好的設計
設計良好的系統應該容易理解,容易改變,容易重用.它實現起來沒有任何特殊的困難,簡明扼要而經濟.它不會散發出**臭味,公司樂於生產這樣的系統,客戶樂於使用這樣的系統,維護人員樂於維護這樣的系統.
設計良好的現代軟體特徵
最小的複雜度:整個系統可以分解為簡單而易於理解的各個部分.
易於維護:程式有良好的可維護性.
鬆散耦合,通過應用類介面中的合理抽象,封裝性以及資訊隱藏等原則,設計出相互關聯盡可能最少的類.
適應變化: 能在不改變系統基本構架的基礎上,適應未來的變化,有良好的擴充套件性,程式可擴充套件,可重用.
有明晰的層次,每層各司其職,有良好分工.
高扇入低扇出:系統很好的利用了較低層次上的工具類,重複**很少或沒有.
有良好的規範:無論多少人參與了專案,從**看來猶如出自一人之手.
使用標準技術.
如何物件導向軟體設計？
軟體設計也分大小，每個軟體開發工程師都有自己的設計，下面談談自己的見解 軟體開發的相關技術更新快，之前掌握的框架如前端的jquery和與jquery相關的框架，後端springmvc，structs，hiberneate等技術都逐漸被淘汰，有些技術公升級成新的技術仍在使用。技術是第一生產率。技術更新...
物件導向軟體設計原則（二） 軟體設計的腐化
我們如何知道軟體設計的優劣呢？以下是一些拙劣設計的症狀，當軟體出現下面任何一種氣味時，就表明軟體正在腐化。僵化性 僵化是指難以對軟體進行改動，即使是簡單的改動。如果單一的改動會導致有依賴關係的模組中的連鎖改動，那麼設計就是僵化的。必須要改動的模組越多，設計就越僵化。大部分開發人員都遇到這樣的情況 他...
軟體設計概述
軟體設計，是乙個很複雜的過程，需要先進行需求採集，然後進行需求分析，最後利用一些專業的設計工具對軟體進行設計，並交付給客戶相應的產出物，比如文件 包含 設計圖 原型等。一般的軟體設計 注 適用於簡單系統，不適用於複雜系統 主要包含概要設計 詳細設計兩部分，也是軟體整個生命週期非常重要的兩個階段，因為...