4. 依賴倒置原則 dip ( dependent inverse principle )
高層模塊不應該依賴于底層模塊，抽象不應該依賴于細節，細節應該依賴于抽象。假定所有的具體類都是回變化的，因此如果一個客戶端依賴于(調用或聲明)具體的類型，那么當這個具體的類型變化時，依賴的客戶端業必須同時進行修改。這些具體的更改可能出現在使用了某個特定的網絡協議，特殊的系統 api 調用，特定的數據庫儲存過程等，這些用法或多或少都會使客戶端調用和具體類型成為鐵板一塊，比較難于重用。 Java 社區中比較熱門的 j2ee 輕量級容器框架 spring 就很好的實現了本原則。
5 .接口隔離原則 isp ( interface segregation principle )
不應該強迫客戶依賴于它們不使用的方法。因為每一個實現接口的對象必須實現所有接口中定義的方法。如果接口的粒度比較小，實現接口的對象可以使用一種即用即付的方式動態實現接口。每個接口的粒度很小，復用起來也非常容易。
這體現了一個趨勢：為了更好的實現重用，接口，函數，模塊和類等傾向于更容易使用的“小”體積。
敏捷軟件開發的宣言和實踐：
軟件開發項目的失敗使得人們開始思考軟件開發的過程，人們希望通過引入嚴格的過程控制產生軟件生命周期中各個階段的文檔和制品來保證軟件的質量。比較出名的業界實施方法論有 cmmi (能力成熟度模型)和 rup (瑞理統一過程)，這些方法論都是重型的。
舉例來說，沒有經過剪裁的 Rup 實現起來，至少需要在全周期完成四十個以上的制品文檔，文檔的編寫維護和源代碼的同步等需要非常多的資源，十人以下的開發團隊一般沒有精力、時間、人員配置完成這些制品。失控的過程的膨脹迫使人們尋找一種快速工作，相應變化的“敏捷的”方法。敏捷團隊提倡通過團隊成員之間充分有效的溝通統一大家的目標，結伴的方式完成開發技術的團隊內傳承，使用“夠用就好”的輕量甚至免費的工具管理過程�？梢哉９ぷ鞯拇a擺在首要地位，只有必要的時候才生產必要的文檔。強調和客戶面對面地交流合作，積極地響應客戶需求的變化而不是遵循機械的計劃。
使用較短的迭代周期，近早和持續提交有價值的軟件給客戶來驗證并修正和用戶需求的吻合程度。提倡可以持續的穩定的開發節奏，長期“小步快走”的方式代替突然的“百米沖刺”。保持設計最優，最簡單的設計并且持續改進，不斷調整。
文章來源于領測軟件測試網 http://www.kjueaiud.com/