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