模式設計

模式設計(Design pattern)是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問,設計模式於己於他人於系統都是多贏的,設計模式使代碼編制真正工程化,設計模式是軟體工程的基石,如同大廈的一塊塊磚石一樣。

模式設計四人幫,模式設計的原則,

模式設計四人幫

GoF(“四人幫”Gang of Four,指Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides四人)的《設計模式》(1995年出版)是第一次將設計模式提升到理論高度,並將之規範化。本書提出了23種基本設計模式,自此,在可復用面向對象軟體的發展過程中,新的大量的設計模式不斷出現。

模式設計的原則

大家都開始注意設計模式。那么,到底我們為什麼要用設計模式呢?這么多設計模式為什麼要這么設計呢?說實話,以前我還真沒搞清楚。就是看大家一口一個"Design pattern",心就有點發虛。於是就買了本"四人幫"的設計模式,結果看得似懂非懂:看的時候好像是懂了,過一會就忘了。可能是本人比較"愚鈍"吧:)),有了點感悟。"獨樂不如眾樂",與大家分享一下,還望指教!
為什麼要提倡"Design Pattern"呢?根本原因是為了代碼復用,增加可維護性。那么怎么才能實現代碼復用呢?OO界有前輩的幾個原則:"開-閉"原則(Open Closed Principal)、里氏代換原則、合成復用原則。設計模式就是實現了這些原則,從而達到了代碼復用、增加可維護性的目的。
1、"開-閉"原則
此原則是由"Bertrand Meyer"提出的。原文是:"Software entities should be open for extension,but closed for modification"。就是說模組應對擴展開放,而對修改關閉。模組應儘量在不修改原(是"原",指原來的代碼)代碼的情況下進行擴展。那么怎么擴展呢?我們看工廠模式"factory pattern":假設中關村有一個賣盜版盤和毛片的小子,我們給他設計一"光碟銷售管理軟體"。我們應該先設計一"光碟"接口。如圖:
[pre]______________
|<>|
| 光碟 |
|_____________|
|+賣() |
| |
|_____________|[/pre]
而盜版盤和毛片是其子類。小子通過"DiscFactory"來管理這些光碟。代碼為:
public class DiscFactory{
public static 光碟 getDisc(java/lang/String.java.html" target="_blank">String name){
return (光碟)java/lang/Class.java.html" target="_blank">Class.forName(name).getInstance();
}
}
有人要買盜版盤,怎么實現呢?
public class 小子{
public static void main(java/lang/String.java.html" target="_blank">String[] args){
光碟 d=DiscFactory.getDisc("盜版盤");
光碟.賣();
}
}
如果有一天,這小子良心發現了,開始賣正版軟體。沒關係,我們只要再創建一個"光碟"的子類"正版軟體"就可以了。不需要修改原結構和代碼。怎么樣?對擴展開發,對修改關閉。"開-閉原則"
工廠模式是對具體產品進行擴展,有的項目可能需要更多的擴展性,要對這個"工廠"也進行擴展,那就成了"抽象工廠模式"。
2、里氏代換原則
里氏代換原則是由"Barbara Liskov"提出的。如果調用的是父類的話,那么換成子類也完全可以運行。比如:
光碟 d=new 盜版盤();
d.賣();
要將"盜版盤"類改為"毛片"類,沒問題,完全可以運行。Java編譯程式會檢查程式是否符合里氏代換原則。還記得java繼承的一個原則嗎?子類override方法的訪問許可權不能小於父類對應方法的訪問許可權。比如"光碟"中的方法"賣"訪問許可權是"public",那么"盜版盤"和"毛片"中的"賣"方法就不能是protected或private,編譯不能通過。為什麼要這樣呢?你想啊:如果"盜版盤"的"賣"方法是private。那么下面這段代碼就不能執行了:
光碟 d=new 盜版盤();
d.賣();
可以說:里氏代換原則是繼承復用的一個基礎。
3、合成復用原則
就是說要少用繼承,多用合成關係來實現。我曾經這樣寫過程式:有幾個類要與資料庫打交道,就寫了一個資料庫操作的類,然後別的跟資料庫打交道的類都繼承這個。結果後來,我修改了資料庫操作類的一個方法,各個類都需要改動。"牽一髮而動全身"!面向對象是要把波動限制在儘量小的範圍。
在Java中,應儘量針對Interface編程,而非實現類。這樣,更換子類不會影響調用它方法的代碼。要讓各個類儘可能少的跟別人聯繫,"不要與陌生人說話"。這樣,城門失火,才不至於殃及池魚。擴展性和維護性才能提高
理解了這些原則,再看設計模式,只是在具體問題上怎么實現這些原則而已。張無忌學太極拳,忘記了所有招式,打倒了"玄冪二老",所謂"心中無招"。設計模式可謂招數,如果先學通了各種模式,又忘掉了所有模式而隨心所欲,可謂OO之最高境界。呵呵,搞笑,搞笑!(JR)
抽象不應該依賴與細節,細節應當依賴與抽象。
要針對接口編程,而不是針對實現編程。
傳遞參數,或者在組合聚合關係中,儘量引用層次高的類。
主要是在構造對象時可以動態的創建各種具體對象,當然如果一些具體類比較穩定,就不必在弄一個抽象類做它的父類,這樣有畫舌添足的感覺
定製服務的例子,每一個接口應該是一種角色,不多不少,不乾不該幹的事,該幹的事都要乾
抽象類不會有實例,一般作為父類為子類繼承,一般包含這個系的共同屬性和方法。
注意:好的繼承關係中,只有葉節點是具體類,其他節點應該都是抽象類,也就是說具體類
是不被繼承的。將儘可能多的共同代碼放到抽象類中。
最少知識原則。不要和陌生人說話。

相關詞條

熱門詞條

聯絡我們