這是我第四次對設計模式進行大規模的掃蕩。第一次是在大三上的時候,自己找設計模式之禪進行掃蕩,第二次是在網上看別人的部落格進行了一次掃蕩,第三次是在面試之前對已經掌握的還有常考的進行掃蕩,第四次是在上設計模式的課程的時候進行的掃蕩。
這個部落格又優點也有缺點。
優點:覆蓋面廣,這個部落格對於所有的設計模式涉及到的知識都有涉及,從六個原則開始到各個模式的類圖,點評都寫得很好,是學習設計模式乙個很好的部落格。
缺點:部分模式太過於簡潔,是最簡單化的設計模式,有些需要進行子類擴充套件的地方沒有進行擴充套件。例如裝飾模式,在這個模式裡面對裝飾者沒有進行擴充套件,裝飾者可以進行不同裝飾的特性沒有進行提現。
本文適合對設計模式有一定了解的人看的,初學者可以去先看看上面那篇部落格。
one:
工廠模式:由於該模式跟現實生活中的工廠很想,所以起名工廠模式。工廠,大家的第一印象是生產某種東西,工廠模式也是確實如此。工廠類是負責生產其他的某種東西的,一般的話是生產某種類物件。在工廠類中可以在乙個函式中生產多種物件,也可以多個函式生產,乙個函式中生產乙個這兩種方式。
public sender producemail()
public sender producesms()
public sender produce(string type) else if ("sms".equals(type)) else
}
另外還有種靜態工廠模式:public class sendfactory
public static sender producesms()
}
這種方式是不用生產工廠物件,可以直接進行呼叫,大家感受一下。
sender sender = sendfactory.producemail();
sender.send();
這是因為靜態函式是隸屬於類的,可以由類直接進行呼叫,所以會方便一些。
two:抽象工廠方法
工廠模式是沒有任何技術含量的但是又簡單易懂所以就擺在第乙個進行講解。沒有類之間的繼承和實現介面啊這些,也就是沒有抽象和具體。
抽象工廠方法對於工廠方法來說的話只是多了乙個抽象的概念。
這裡面在provider抽象類或者是介面中定義乙個produce()函式,然後由不同的子類對其進行不同的實現,這裡也即是生產不同的產品。
打個比方;provider抽象級別的公司,也就是概念中的公司。下面兩個是具體的比如說賣魚的和賣雞的,你要宰好的魚就去生產魚的公司,你要買雞就去生產雞的公司。
優點:這個對於工廠模式來說引入了抽象,可以進行很好的擴充套件。比如現在有乙個賣鵝的公司加進來的話,我們就可以再不用更改其他類的前提下進行擴充套件。
three:單例模式
這個模式來說基本的就是三點:私有靜態例項,私有的建構函式,公有的靜態工程方法,建立例項。
public class singleton
/* 靜態工程方法,建立例項 */
public static singleton getinstance()
return instance;
} }
這個顯然不能適用於多執行緒,想去了解多執行緒下的朋友可以去看劍指offer,裡面有詳細的講解。
four:建造者模式
建造者模式中對於分工是分的很細的,比如說造車。
car類中是car的基本屬性。
package com.zcl.design.builder;
public class car
public void setwheel(string wheel)
public string getengine()
public void setengine(string engine)
public string getcarframe()
public void setcarframe(string carframe)
public void getinformation()
}
對於實際的生產者來說我們引入抽象,介面ibuilder
package com.zcl.design.builder;
public inte***ce ibuilder
實現介面:
package com.zcl.design.builder;
/** * @author zcl 實際的生產者
*/public class carbuilder implements ibuilder
@override
public void buildwheel()
@override
public void buildengine()
@override
public void buildcarframe()
public car carbuildover()
}
然後builder強對於其他設計模式來說多的是乙個導演類,該類的作用是可以決定採用何種順序或者方式來組裝的車子。
package com.zcl.design.builder;
/** * @author zcl
* 導演類起到封裝的作用,避免高層模組深入到建造者內部實現類
* 決定汽車的建造順序
*/public class cardirector
}
在上面的類中,我們可以看到早buildcar函式中我們決定了car的組裝的順序,我們也可以在建立乙個類然後更換它的組裝順序,然後達到客戶的相關要求。
下面是client即測試類。
package com.zcl.design.builder;
public class client
}
C 設計模式之我見 四
今天咱們接著上一節的行為型模式觀察者模式 oberver pattern 中介者模式 mediator pattern 備忘錄模式 memento pattern 給大家繼續講。在前這幾節中,因為時間緊促,可能有些詮釋的不到位,可能多少有點瑕疵,因為不同人的理解是不同的概念。當然希望廣大讀者多提建議...
C 設計模式之我見 四
模版方法模式 template method 命令模式 command pattern 迭代器模式 iterator pattern 觀察者模式 oberver pattern 中介者模式 mediator pattern 備忘錄模式 memento pattern 直譯器模式 interprete...
C 設計模式之我見 三
composite pattern 外觀模式 fa ade pattern 享元模式 flyweight pattern 模式 proxy pattern 組合模式 composite pattern 將物件以樹形結構組織起來,以達成 部分 整體 的層次結構,使得客戶端對單個物件和組合物件的使用具有...