Factory Method(工廠方法)
1 應(yīng)用場景
在軟件系統(tǒng)中糕簿,經(jīng)常面臨著創(chuàng)建對象的工作;由于需求的變化狡孔,需要創(chuàng)建的對象的具體類型經(jīng)常變化懂诗。
2 定義與解釋
定義一個用于創(chuàng)建對象的接口,讓子類決定具體實例化哪個類苗膝。Factory Method是的一個類的實例化延遲到子類响禽。(目的是解耦,手段是虛函數(shù))
考慮之前在學(xué)習(xí)觀察者模式的文件分割器例子,通常來講芋类,我們很可能寫出這樣的代碼:
BinarySplitter * splitter= new BinarySplitter();//依賴具體類
聲明一個文件分割器的對象隆嗅,接下來再使用它。但實際上這是不符合”面向接口編程”的侯繁,它直接的使用了BinarySplitter具體類進(jìn)行編程胖喳。我們可能會有二進(jìn)制分割器,文本分割器贮竟,視頻分割器等等丽焊。那我們接下來就會想到,使用一個抽象類接口咕别,然而這樣只能部分地消除依賴:
ISplitter * splitter = //不再依賴具體類
new BinarySplitter();//仍然依賴具體類技健,BinarySplitter不存在時無法編譯通過
在這種情況下,只要有依賴就仍然做不到解耦惰拱。而后邊又無法搞成接口類雌贱,(接口類無法執(zhí)行new操作)。這就引入了工廠方法偿短,這是面向接口編程的第一步需求欣孤。
工廠方法就是用一個函數(shù)來代替new操作,這個函數(shù)要能夠產(chǎn)生各種不同的分割器昔逗,我們就又想到了虛函數(shù)(虛函數(shù)和繼承機(jī)制是延遲決定的唯一方法)降传,如下圖工廠方法的具體代碼,不同的工廠產(chǎn)生不同的分割器:
class SplitterFactory{
public:
virtual ISplitter* CreateSplitter()=0;
virtual ~SplitterFactory(){}
};
//具體工廠
class BinarySplitterFactory: public SplitterFactory{
public:
virtual ISplitter* CreateSplitter(){
return new BinarySplitter();
}
};
class TxtSplitterFactory: public SplitterFactory{
public:
virtual ISplitter* CreateSplitter(){
return new TxtSplitter();
}
};
在使用這個分割器的時候勾怒,如下面的MFC中的例子:
{
SplitterFactory* factory;//工廠
public:
MainForm(SplitterFactory* factory){ //利用傳入?yún)?shù)來決定用什么文件分割器磷箕,這就把"變化"的范圍限制在MainForm之外了
this->factory=factory;
}
void Button1_Click(){
ISplitter * splitter=
factory->CreateSplitter(); //創(chuàng)造性的做出了一個多態(tài)的new
splitter->split();
}
};
Abstract Factory(抽象工廠)
1 應(yīng)用場景
在軟件系統(tǒng)中僚祷,經(jīng)常面臨著創(chuàng)建”一系列相互依賴的對象”(和上邊的唯一不同就是一系列相互依賴)的工作唯咬;由于需求的變化戳杀,需要創(chuàng)建的對象的具體類型經(jīng)常變化。
2 定義與解釋
提供一個接口卡乾,讓該接口負(fù)責(zé)創(chuàng)建一系列”相關(guān)或相互依賴的對象” 翼悴,無需指定它們具體的類。
考慮在軟件的層次架構(gòu)中的數(shù)據(jù)訪問層幔妨,需要訪問數(shù)據(jù)庫○惺辏現(xiàn)在使用的是SQL的數(shù)據(jù)庫,但是以后有可能會使用其他種類的數(shù)據(jù)庫比如Oracle等误堡。我們的想法還是進(jìn)行面向接口的編程古话,應(yīng)用工廠方法之后我們不難寫出如下的接口:
//數(shù)據(jù)庫訪問有關(guān)的基類
class IDBConnection{
};
class IDBConnectionFactory{
public:
virtual IDBConnection* CreateDBConnection()=0;
};
//支持SQL Server
class SqlConnection: public IDBConnection{
};
class SqlConnectionFactory:public IDBConnectionFactory{
};
//支持Oracle
class OracleConnection: public IDBConnection{
};
class OracleConnectionFactory: public IDBConnectionFactory {
};
但是這種情況下,用戶需要手動搭配DBConnection锁施,DataReader存在用戶錯誤的把不同類型的操作拼到一起的問題陪踩。
因此我們希望能進(jìn)一步進(jìn)項抽象杖们,提取這些工廠的特質(zhì),就產(chǎn)生了抽象工廠方法肩狂。其實更應(yīng)該叫做”家族工廠”“工廠組”之類摘完,它把不同的操作用同一個工廠類產(chǎn)生,防止了某些用戶錯誤地把不同種類的操作混雜在一起(例如SQL的Command配上Oracle的Reader)傻谁。
class IDBFactory{
public:
virtual IDBConnection* CreateDBConnection()=0;
virtual IDBCommand* CreateDBCommand()=0;
virtual IDataReader* CreateDataReader()=0;
};
class SqlDBFactory:public IDBFactory{
public:
virtual IDBConnection* CreateDBConnection()=0;
virtual IDBCommand* CreateDBCommand()=0;
virtual IDataReader* CreateDataReader()=0;
};
Prototype(原型)
1 應(yīng)用場景
在軟件系統(tǒng)中孝治,經(jīng)常面臨著創(chuàng)建”某些結(jié)構(gòu)復(fù)雜的的對象”的工作;由于需求的變化审磁,需要創(chuàng)建的對象的具體類型經(jīng)常變化谈飒,但是他們卻擁有比較比較一致的接口。
2 定義與解釋
使用一個原型實例指定創(chuàng)建對象的種類态蒂,通過復(fù)制這個原型創(chuàng)建對象杭措。
仍然考慮文件分割器,我們類比工廠方法钾恢。原型模式是一種特殊的創(chuàng)建手素,通過克隆(復(fù)制構(gòu)造)來進(jìn)行創(chuàng)建赘那。
//抽象類
class ISplitter{
public:
virtual void split()=0;
virtual ISplitter* clone()=0; //通過克隆自己來創(chuàng)建對象
virtual ~ISplitter(){}
};
//具體類,直接利用拷貝構(gòu)造函數(shù)進(jìn)行配置
class BinarySplitter : public ISplitter{
public:
virtual ISplitter* clone(){
return new BinarySplitter(*this);
}
};
但是這種情況下氯质,用戶需要手動搭配DBConnection募舟,DataReader存在用戶錯誤的把不同類型的操作拼到一起的問題。
在使用這個抽象的時候闻察,如下面的例子拱礁。必須強調(diào)原型對象盡管已經(jīng)存在了,但是它不是用來更改的辕漂,只能用來復(fù)制呢灶。(否則不同的操作之間就可能產(chǎn)生影響,相當(dāng)于原型有了初值钉嘹。)
class MainForm : public Form
{
ISplitter* prototype;//原型對象
public:
MainForm(ISplitter* prototype){
this->prototype=prototype; //讓原型對象指向傳過來的原型
}
void Button1_Click(){
ISplitter * splitter=
prototype->clone(); //克隆原型
splitter->split();
}
上課內(nèi)容摘要
A. 工廠模式(Factory Method)
結(jié)構(gòu)
要點總結(jié)
B. 抽象工廠(Abstract Factory)
結(jié)構(gòu)
要點總結(jié)
C. 原型模式(Prototype)
結(jié)構(gòu)
要點總結(jié)
D. 構(gòu)建器(Builder)
結(jié)構(gòu)
要點總結(jié)
-
“接口隔離”模式
動機(jī)組件的客戶和組件中各種復(fù)雜的子系統(tǒng)有了過多的耦合褪储,隨著外部客戶程序和各子系統(tǒng)的演化卵渴,這種過多的耦合面臨很多變化的挑戰(zhàn)。如何簡化外部客戶程序和系統(tǒng)間的交互接口鲤竹?如何將外部客戶程序的演化和內(nèi)部子系統(tǒng)的變化之間的依賴相互解耦浪读?
在組件構(gòu)建過程中驮肉,某些接口之間直接的依賴常常會帶來很多問題,甚至根本無法實現(xiàn)已骇。采用添加一層間接(穩(wěn)定)接口离钝,來隔離本來互相緊密關(guān)聯(lián)的接口是一種常見的解決方案。
A. 門面模式(Facade)
結(jié)構(gòu)
要點總結(jié)
B. 代理模式(Proxy)
結(jié)構(gòu)
要點總結(jié)
C. 適配器(Adapter)
結(jié)構(gòu)
要點總結(jié)
D. 中介者(Mediator)
-動機(jī)在軟件構(gòu)建過程中诚镰,經(jīng)常會出現(xiàn)多個對象互相關(guān)聯(lián)交互的情況,對象之間常常會維持一種復(fù)雜的引用關(guān)系祥款,如果遇到一些需求的更改清笨,這種直接的引用關(guān)系將面臨不斷的變化。這種情況下刃跛,我們可使用一個“中介對象”來管理對象間的關(guān)聯(lián)關(guān)系抠艾,避免相互交互的對象之間的緊耦合引用關(guān)系,從而更好地抵御變化桨昙。
模式定義
結(jié)構(gòu)
};