敏捷設計
•全局視圖和軟件一起演化
•設計儘可能適合當前系統，關注當前系統結構
•增量地演化出系統最佳架構和設計
•設計和架構過程是持續不斷進行的
•從根本上講，源代碼就是設計
•敏捷設計是一個過程，不是一個事件，是一個持續的應用原則、模式以及實踐來改進軟件結構和可讀性的過程
•敏捷設計步驟
–遵循敏捷實踐去發現問題
–應用設計原則去診斷問題
–應用適當模式去解決問題
設計臭味
•設計臭味
–僵化性（rigidity）——連鎖改動
–脆弱性（fragility）——耦合、易遭破壞
–頑固性（immobility）——難以重用
–粘滯性（viscosity）——難以做正確的事情
–不必要的複雜性（needlesscomplexity）——過度設計
–不必要的重複（needlessrepetition）——忽略抽象
–晦澀性（opacity）——難以理解
SRP(單一職責原則)
•內聚性
–一個模塊的組成元素之間的功能相關性
•SRP
–一個類應該只有一個發生變化的原因，及一個類應該只有一個職責
•職責
–發生變化的原因
–需求變化反應爲職責的變化
•軟件設計，就是要發現職責，並把它們相互分離
OCP(開放-封閉原則)
•封閉是建立在抽象的基礎之上的
•只受一次愚弄
•刺激變化：測試驅動、快速交付
•正確判斷各種變化的可能
•一直等到變化發生時才採取行動
•OCP是面向對象設計的核心所在
•拒絕不成熟的抽象和抽象本身一樣重要
•OCP背後的主要機制是抽象和多態
•有經驗的設計人員希望自己對用戶和應用領域很瞭解，能夠以此來判斷各種變化的可能性。然後，他可以讓設計對於最有可能發生的變化遵循OCP原則
LSP(Liskov替換原則)
•子類型必須能夠替換掉它們的基類型，替換後，程序的行爲功能不變
•一個自相容的設計未必就和所有的用戶程序相容
•一個模型的有效性只能通過它的客戶程序來表現
•在考慮一個特定設計是否恰當時，不能完全孤立的來看這個解決方案，必須根據該設計的使用者所作出的合理假設來審視它（這些合理的假設常常以斷言的形式出現在爲基類編寫的單元測試中）
•違反LSP往往是很微妙的
基於契約的設計
•LSP清楚的指出，OOD中的IS-A關係是就行爲方式而言的，行爲方式是可以進行合理假設的，是客戶程序所依賴的。
•使用基於契約的設計可以使LSP明確化
•基於契約的設計
–在重新聲明派生類的例程中，只能使用相等或更弱的前置條件，只能使用相等或更強的後置條件
–若違反了這條原則，則必定違反LSP原則
•爲每個方法的註釋添加前置和後置條件
•通過單元測試來指定契約
DIP(依賴倒置原則)
•DIP
–高層模塊不應該依賴底層模塊，二者都應該依賴於抽象
–抽象不應該依賴於細節。細節應該依賴於抽象
•框架設計的核心原則
•DIP解析
–高層模塊即客戶端或使用方，底層模塊即服務端
–應由使用方提出所需的接口，由服務方來實現這些接口的具體功能
–因此軟件開發的過程應該是自上而下的
•抽象接口歸客戶端所有
ISP(接口隔離原則)
•不應該強迫客戶程序依賴它們並不使用的方法/接口。
•分離客戶就是分離接口。