設計模式遵循的一般原則：
乙個軟體實體應當對擴充套件開發,對修改關閉.說的是,再設計乙個模組的時候,應當使這個模組可以在不被修改的前提下被擴充套件.換言之,應當可以在不必修改源**的情況下改變這個模組的行為，在保持系統一定穩定性的基礎上，對系統進行擴充套件。這是物件導向設計（ood）的基石，也是最重要的原則。
(1).由barbar liskov(芭芭拉.黎克特制)提出，是繼承復用的基石。(2).嚴格表達:如果每乙個型別為t1的物件o1,都有型別為t2的物件o2,使得以t1定義的所有程式p在所有的物件o1都代換稱o2時,程式p的行為沒有變化,那麼型別t2是型別t1的子型別.
換言之,乙個軟體實體如果使用的是乙個基類的話,那麼一定適用於其子類,而且它根本不能察覺出基類物件和子類物件的區別.只有衍生類可以替換基類，軟體單位的功能才能不受影響，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新功能。
(3).反過來的代換不成立
(5).該類西方著名的例程為:正方形是否是長方形的子類(答案是"否")。類似的還有橢圓和圓的關係。
(6).應當盡量從抽象類繼承,而不從具體類繼承,一般而言,如果有兩個具體類a,b有繼承關係,那麼乙個最簡單的修改方案是建立乙個抽象類c,然後讓類a和b成為抽象類c的子類.即如果有乙個由繼承關係形成的登記結構的話,那麼在等級結構的樹形圖上面所有的樹葉節點都應當是具體類;而所有的樹枝節點都應當是抽象類或者介面.
(7)."基於契約設計(design by constract),簡稱dbc"這項技術對liskov代換原則提供了支援.該項技術bertrand meyer伯特蘭做過詳細的介紹:
使用dbc,類的編寫者顯式地規定針對該類的契約.客戶**的編寫者可以通過該契約獲悉可以依賴的行為方式.契約是通過每個方法宣告的前置條件(preconditions)和後置條件(postconditions)來指定的.要使乙個方法得以執行,前置條件必須為真.執行完畢後,該方法要保證後置條件為真.就是說,在重新宣告派生類中的例程(routine)時,只能使用相等或者更弱的前置條件來替換原始的前置條件,只能使用相等或者更強的後置條件來替換原始的後置條件.
要求客戶端依賴於抽象耦合.(1)表述:抽象不應當依賴於細節,細節應當依賴於抽象.(program to an inte***ce, not an implementaction)
(2)表述二:針對介面程式設計的意思是說,應當使用介面和抽象類進行變數的型別宣告,參量的型別宣告,方法的返還型別宣告,以及資料型別的轉換等.不要針對實現程式設計的意思就是說,不應當使用具體類進行變數的型別宣告,參量型別宣告,方法的返還型別宣告,以及資料型別的轉換等.
要保證做到這一點,乙個具體的類應等只實現介面和抽象類中宣告過的方法,而不應當給出多餘的方法.
只要乙個被引用的物件存在抽象型別,就應當在任何引用此物件的地方使用抽象型別,包括參量的型別宣告,方法返還型別的宣告,屬性變數的型別宣告等.
(3)介面與抽象的區別就在於抽象類可以提供某些方法的部分實現,而介面則不可以,這也大概是抽象類唯一的優點.如果向乙個抽象類加入乙個新的具體方法,那麼所有的子型別一下子就都得到得到了這個新的具體方法,而介面做不到這一點.如果向乙個介面加入了乙個新的方法的話,所有實現這個介面的類就全部不能通過編譯了,因為它們都沒有實現這個新宣告的方法.這顯然是介面的乙個缺點.
(4)乙個抽象類的實現只能由這個抽象類的子類給出,也就是說,這個實現處在抽象類所定義出的繼承的登記結構中,而由於一般語言都限制乙個類只能從最多乙個超類繼承,因此將抽象作為型別定義工具的效能大打折扣.
反過來,看介面,就會發現任何乙個實現了乙個介面所規定的方法的類都可以具有這個介面的型別,而乙個類可以實現任意多個介面.
(5)從**重構的角度上講,將乙個單獨的具體類重構成乙個介面的實現是很容易的,只需要宣告乙個介面,並將重要的方法新增到介面宣告中,然後在具體類定義語句中加上保留字以繼承於該介面就行了.
而作為乙個已有的具體類新增乙個抽象類作為抽象型別不那麼容易,因為這個具體類有可能已經有乙個超類.這樣一來,這個新定義的抽象類只好繼續向上移動,變成這個超類的超類,如此迴圈,最後這個新的抽象類必定處於整個型別等級結構的最上端,從而使登記結構中的所有成員都會受到影響.
(6)介面是定義混合型別的理想工具,所為混合型別,就是在乙個類的主型別之外的次要型別.乙個混合型別表明乙個類不僅僅具有某個主型別的行為,而且具有其他的次要行為.
(7)聯合使用介面和抽象類:
由於抽象類具有提供預設實現的優點,而介面具有其他所有優點,所以聯合使用兩者就是乙個很好的選擇.
首先,宣告型別的工作仍然介面承擔的,但是同時給出的還有乙個抽象類,為這個介面給出乙個預設實現.其他同屬於這個抽象型別的具體類可以選擇實現這個介面,也可以選擇繼承自這個抽象類.如果乙個具體類直接實現這個介面的話,它就必須自行實現所有的介面;相反,如果它繼承自抽象類的話,它可以省去一些不必要的的方法,因為它可以從抽象類中自動得到這些方法的預設實現;如果需要向介面加入乙個新的方法的話,那麼只要同時向這個抽象類加入這個方法的乙個具體實現就可以了,因為所有繼承自這個抽象類的子類都會從這個抽象類得到這個具體方法.這其實就是預設介面卡模式(defaule adapter).
(8)什麼是高層策略呢?它是應用背後的抽象,是那些不隨具體細節的改變而改變的真理. 它是系統內部的系統____隱喻.
（1）乙個類對另外乙個類的依賴是建立在最小的介面上。（2）使用多個專門的介面比使用單一的總介面要好.根據客戶需要的不同,而為不同的客戶端提供不同的服務是一種應當得到鼓勵的做法.就像"看人下菜碟"一樣,要看客人是誰,再提供不同檔次的飯菜.
（3）胖介面會導致他們的客戶程式之間產生不正常的並且有害的耦合關係.當乙個客戶程式要求該胖介面進行乙個改動時,會影響到所有其他的客戶程式.因此客戶程式應該僅僅依賴他們實際需要呼叫的方法.
在乙個新的物件裡面使用一些已有的物件,使之成為新物件的一部分;新的物件通過這些向物件的委派達到復用已有功能的目的.這個設計原則有另乙個簡短的表述:要盡量使用合成/聚合,盡量不要使用繼承.
就是說,乙個物件應當對其他物件有盡可能少的了了解.迪公尺特法則最初是用來作為物件導向的系統設計風格的一種法則,與2023年秋天由ian holland在美國東北大學為乙個叫做迪公尺特(demeter)的專案設計提出的,因此叫做迪公尺特法則[lieb89][lieb86].這條法則實際上是很多著名系統,比如火星登陸軟體系統,木星的歐羅巴衛星軌道飛船的軟體系統的指導設計原則.
沒有任何乙個其他的oo設計原則象迪公尺特法則這樣有如此之多的表述方式,如下幾種:
(1)只與你直接的朋友們通訊(only talk to your immediate friends)
(2)不要跟"陌生人"說話(don't talk to strangers)
(3)每乙個軟體單位對其他的單位都只有最少的知識,而且侷限於那些本單位密切相關的軟體單位.
就是說,如果兩個類不必彼此直接通訊,那麼這兩個類就不應當發生直接的相互作用,如果其中的乙個類需要呼叫另乙個類的某乙個方法的話,可以通過第三者**這個呼叫。
就乙個類而言,應該僅有乙個引起它變化的原因,如果你能想到多於乙個的動機去改變乙個類,那麼這個類就具有多於乙個的職責.應該把多於的指責分離出去,分別再建立一些類來完成每乙個職責.另外：常說的oo五大原則就是指其中的 ：
1、單一職責原則；
2、開放閉合原則；
3、黎克特制替換原則；
4、依賴倒置原則；
5、介面隔離原則。
物件導向程式設計五大原則
單一職責原則srp single responsibility principle 開放封閉原則ocp open close principle liskov替換原則lsp liskov substitution principle 依賴倒置原則dip dependency invertion pr...
物件導向程式設計五大原則
單一職責原則srp single responsibility principle 開放封閉原則ocp open close principle liskov替換原則lsp liskov substitution principle 依賴倒置原則dip dependency invertion pr...
物件導向程式設計五大原則
單一職責原則srp singleresponsibilityprinciple 開放封閉原則ocp open closeprinciple liskov替換原則lsp liskovsubstitutionprinciple 依賴倒置原則dip dependencyinvertionprinciple...