敏捷開發的幾個大的原則
1.單一職責 srp
2.開放-封閉 ocp
3.liskov替換原則 lsp ？
4.依賴倒置 dip
5.介面隔離 isp
敏捷開發提倡簡單設計的實踐，「並在實現新需求時抓住機會改進設計」以對同類性質的改動封閉，做到由需求的變化驅動設計的進化（我們不能因為設計的退化而責怪需求的變化），同時經驗在此起到十分重要的作用，如有經驗的設計人員可以憑經驗在初始設計時做出必要的抽象來滿足ocp原則等，或是在需求變動時確定系統所需的抽象（所需的封閉），當然應及早的刺激這種變化的出現（如測試驅動的開發方法）。
ood承諾了一系列的好處（靈活性可重用性可維護性），用oo語言設計開發，若要方便的得到這些所謂的好處，有一系列的原則是要遵循的，如srp，ocp，lsp，isp等。
srp（單一職責原則）維護類的簡單性，類不應承擔乙個以上令其變化的原因，否則應考慮分離並重新構造類，但如果的應用的變化方式總是導致類中的職責同時變化，卻沒必要分離他們
ocp（開閉原則）使oo系統做到對擴充套件開放，對修改封閉。ocp的遵循關鍵在於抽象，其主要實現方式有：定義介面描繪所需的操作，client只需關注介面的呼叫，子型別可以以任何其選擇的方式實現介面，即所謂的stategy模式，或者定義抽象類並於其中實現公共操作，個性操作定義為abstract或virtual，由子型別負責個性化實現，通過此兩法，將功能的通用部分和實現細節分離出來。當然，設計人員應該確定（猜測或憑經驗）系統對哪種變化做到封閉，因為不可能對所有變化做到封閉，如《敏捷模式實踐》中提到shape型別排序處理問題，為做到對排序安排（或變動）的封閉（使得各子型別間無需相互知曉，也可以做到自由安排排序順序），選擇使用「資料驅動」的方式（即單獨構造結構表示排序安排—其中以子類型別在結構中的排列位置表先後），於shape基類中實現一次precedes操作即可，子型別無需分別實現。ocp作為ood核心所在依賴抽象來實現，但敏捷設計（或者說好的設計）拒絕不成熟的抽象，程式僅應對頻繁變化的部分做出抽象。
liskov替換原則是使得ocp成為可能的原則之一，強調「子型別subtype必須能夠替換掉它們的基型別basetype」，控制oo的繼承關係安排，在ood用is-a來確定類間的繼承關係，lsp指出這種is-a關係是就行為方式（即類的各操作）而言的，而行為方式是可以合理假設的，是客戶程式所依賴的。為遵循lsp，可借用dbc（design by contract）的操作前置條件和後置條件，「要使操作得以執行，前置條件必須為真，執行完畢後，該操作要確保後置條件為真」（為每個方法註明其前置和後置條件十分有幫助），如此，則「在重新宣告派生類中操作時，只能使用相等或更弱的前置條件來替換原始的前置條件，只能用相等或更強的後置條件來替換原始的後置條件」（inte***ce和其實現類間 抽象方法和其實現 此二者一定滿足前述條件）。同時亦可用前述ocp遵循所用的二模式使設計符合lsp，另外子型別中的異常丟擲應考慮在遵循lsp的範圍內。
關於提取公共部分的設計工具：「提取公共職責放入超類中，稍後新增的新的子型別可能會以新的方式支援同樣的職責，此時原來的超類可能會是乙個抽象類」。
dip（依賴倒置原則），作為framework的設計核心，其相對於傳統軟體設計而言，通常（傳統）軟體設計中採用結構化設計用高層模組直接呼叫底層模組，這樣高層模組將嚴重依賴於底層模組的變動，在ood中通過為高層模組定義所需使用的服務介面，底層模組現實這樣的介面，高層模組通過抽象介面使用下一層（strategy模式所宣告的），如此看來介面的擁有者一般是其使用者而非其實現者。通常為了滿足dip-良好ood的基本底層機制，我麼需要找出系統中潛在的抽象，而抽象通常是那些不隨具體細節變化而變化的東東。
isp介面隔離原則，如srp維護類的簡單性一樣，isp用於維護介面的簡單和必要性，因為介面是為客戶呼叫的，因此其應該是「大小尺寸合適的」，「胖」介面顯然對呼叫者造成累贅，isp則用於將「胖」介面分離成多個合適的介面。
敏捷開發的幾個大的原則
b 敏捷開發的幾個大的原則 b 1.單一職責 srp 2.開放 封閉 ocp 3.liskov替換原則 lsp 4.依賴倒置 dip 5.介面隔離 isp 敏捷開發提倡簡單設計的實踐，並在實現新需求時抓住機會改進設計 以對同類性質的改動封閉，做到由需求的變化驅動設計的進化 我們不能因為設計的退化而責...
敏捷開發的原則
一 單一職責原則 the single responsibility principal srp 就是說盡量的單一化類的功能，不要使類具有多個功能。如果類具有多個功能時，任意乙個功能的修改都需要改寫這個類，也就會影響其他的類，而這些類根本沒有使用修改的這個功能。如果單一化功能，這種情況就可以避免。例...
敏捷開發原則
原則一 我們最先要做的是通過盡早的持續的交付，有價值的軟體來時客戶滿意，初期交付的系統中所包含的功能越少，最終交付的系統的質量就越高，交付的越頻繁，最終產品的質量就越高。原則二即使到了開發的後期也歡迎改變需求敏捷過程，利用變化來為客戶創造競爭優勢。原則三經常性的交付，可以工作的軟體交付的間隔可以從幾...