很多人對設計模式并不了解。其實設計模式是一組代碼設計經驗，已經被重復使用并且為大多數人所熟知。設計模式的使用是為了重用代碼，使其他人更容易理解代碼并確保代碼的可靠性。毫無疑問，設計模式對其他人和系統都是互惠互利的。設計模式使代碼編寫真正地工程化；設計模式是軟件工程的基石，就像建筑物的結構一樣。那么設計模式有哪些原則？

　　里氏代換原則

　　里氏代換原則是由"BarbaraLiskov"提出的。如果調用的是父類的話，那么換成子類也完全可以運行。比如：光盤d=new盜版盤();d.賣();要將"盜版盤"類改為"毛片"類，沒問題，完全可以運行。Java編譯程序會檢查程序是否符合里氏代換原則。還記得java繼承的一個原則嗎？子類override方法的訪問權限不能小于父類對應方法的訪問權限。比如"光盤"中的方法"賣"訪問權限是"public"，那么"盜版盤"和"毛片"中的"賣"方法就不能是protected或private，編譯不能通過。為什么要這樣呢？你想?。喝绻?quot;盜版盤"的"賣"方法是private。那么下面這段代碼就不能執行了：光盤d=new盜版盤();d.賣();可以說：里氏代換原則是繼承復用的一個基礎。

　　合成復用原則

　　就是說要少用繼承，多用合成關系來實現。我曾經這樣寫過程序：有幾個類要與數據庫打交道，就寫了一個數據庫操作的類，然后別的跟數據庫打交道的類都繼承這個。結果后來，我修改了數據庫操作類的一個方法，各個類都需要改動。"牽一發而動全身"！面向對象是要把波動限制在盡量小的范圍。

　　在Java中，應盡量針對Interface編程，而非實現類。這樣，更換子類不會影響調用它方法的代碼。要讓各個類盡可能少的跟別人聯系，"不要與陌生人說話"。這樣，城門失火，才不至于殃及池魚。擴展性和維護性才能提高。

　　理解了這些原則，再看設計模式，只是在具體問題上怎么實現這些原則而已。張無忌學太極拳，忘記了所有招式，打倒了"玄冪二老"，所謂"心中無招"。設計模式可謂招數，如果先學通了各種模式，又忘掉了所有模式而隨心所欲，可謂OO之最高境界。

　　依賴倒轉原則抽象不應該依賴與細節，細節應當依。

　　依賴倒轉原則

　　要針對接口編程，而不是針對實現編程。傳遞參數，或者在組合聚合關系中，盡量引用層次高的類。主要是在構造對象時可以動態的創建各種具體對象，當然如果一些具體類比較穩定，就不必在弄一個抽象類做它的父類，這樣有畫舌添足的感覺接口隔離原則定制服務的例子。

　　接口隔離原則

　　一種角色，不多不少，不干不該干的事，該干的事都要干抽象類抽象類不會有實例

　　抽象類

　　類為子類繼承，一般包含這個系的共同屬性和方法。注意：好的繼承關系中，只有葉節點是具體類，其他節點應該都是抽象類，也就是說具體類是不被繼承的。將盡可能多的共同代碼放到抽象類中。迪米特法則最少知識原則。不要和陌生人說話。

　　上述就是關于設計模式有哪些原則的全部內容，想了解更多關于設計模式的信息，請繼續關注中培偉業。