(Boolan) C++設(shè)計(jì)模式 第二周筆記

Factory Method(工廠方法)

1 應(yīng)用場(chǎng)景

在軟件系統(tǒng)中,經(jīng)常面臨著創(chuàng)建對(duì)象的工作;由于需求的變化,需要?jiǎng)?chuàng)建的對(duì)象的具體類型經(jīng)常變化。

2 定義與解釋

定義一個(gè)用于創(chuàng)建對(duì)象的接口,讓子類決定具體實(shí)例化哪個(gè)類。 Factory Method是的一個(gè)類的實(shí)例化延遲到子類。 (目的是解耦,手段是虛函數(shù))

考慮之前在學(xué)習(xí)觀察者模式的文件分割器例子,通常來(lái)講,我們很可能寫出這樣的代碼:

BinarySplitter * splitter= new BinarySplitter();//依賴具體類

聲明一個(gè)文件分割器的對(duì)象,接下來(lái)再使用它。 但實(shí)際上這是不符合”面向接口編程”的,它直接的使用了BinarySplitter具體類進(jìn)行編程。 我們可能會(huì)有二進(jìn)制分割器,文本分割器,視頻分割器等等。 那我們接下來(lái)就會(huì)想到,使用一個(gè)抽象類接口,然而這樣只能部分地消除依賴:

ISplitter * splitter = //不再依賴具體類

new BinarySplitter();//仍然依賴具體類,BinarySplitter不存在時(shí)無(wú)法編譯通過(guò)

在這種情況下,只要有依賴就仍然做不到解耦。 而后邊又無(wú)法搞成接口類,(接口類無(wú)法執(zhí)行new操作)。 這就引入了工廠方法,這是面向接口編程的第一步需求。

工廠方法就是用一個(gè)函數(shù)來(lái)代替new操作,這個(gè)函數(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();

}

};

在使用這個(gè)分割器的時(shí)候,如下面的MFC中的例子:

{

SplitterFactory* factory;//工廠

public:

MainForm(SplitterFactory* factory){ //利用傳入?yún)?shù)來(lái)決定用什么文件分割器,這就把"變化"的范圍限制在MainForm之外了

this->factory=factory;

}

? ? void Button1_Click(){

? ? ISplitter * splitter=

factory->CreateSplitter(); //創(chuàng)造性的做出了一個(gè)多態(tài)的new

splitter->split();

? ? }

};

Abstract Factory(抽象工廠)

1 應(yīng)用場(chǎng)景

在軟件系統(tǒng)中,經(jīng)常面臨著創(chuàng)建”一系列相互依賴的對(duì)象”(和上邊的唯一不同就是一系列相互依賴)的工作;由于需求的變化,需要?jiǎng)?chuàng)建的對(duì)象的具體類型經(jīng)常變化。

2 定義與解釋

提供一個(gè)接口,讓該接口負(fù)責(zé)創(chuàng)建一系列”相關(guān)或相互依賴的對(duì)象” ,無(wú)需指定它們具體的類。

考慮在軟件的層次架構(gòu)中的數(shù)據(jù)訪問(wèn)層,需要訪問(wèn)數(shù)據(jù)庫(kù)。 現(xiàn)在使用的是SQL的數(shù)據(jù)庫(kù),但是以后有可能會(huì)使用其他種類的數(shù)據(jù)庫(kù)比如Oracle等。 我們的想法還是進(jìn)行面向接口的編程,應(yīng)用工廠方法之后我們不難寫出如下的接口:

//數(shù)據(jù)庫(kù)訪問(wèn)有關(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 {

};

但是這種情況下,用戶需要手動(dòng)搭配DBConnection,DataReader存在用戶錯(cuò)誤的把不同類型的操作拼到一起的問(wèn)題。

因此我們希望能進(jìn)一步進(jìn)項(xiàng)抽象,提取這些工廠的特質(zhì),就產(chǎn)生了抽象工廠方法。 其實(shí)更應(yīng)該叫做”家族工廠”“工廠組”之類,它把不同的操作用同一個(gè)工廠類產(chǎn)生,防止了某些用戶錯(cuò)誤地把不同種類的操作混雜在一起(例如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)用場(chǎng)景

在軟件系統(tǒng)中,經(jīng)常面臨著創(chuàng)建”某些結(jié)構(gòu)復(fù)雜的的對(duì)象”的工作;由于需求的變化,需要?jiǎng)?chuàng)建的對(duì)象的具體類型經(jīng)常變化,但是他們卻擁有比較比較一致的接口。

2 定義與解釋

使用一個(gè)原型實(shí)例指定創(chuàng)建對(duì)象的種類,通過(guò)復(fù)制這個(gè)原型創(chuàng)建對(duì)象。

仍然考慮文件分割器,我們類比工廠方法。 原型模式是一種特殊的創(chuàng)建,通過(guò)克隆(復(fù)制構(gòu)造)來(lái)進(jìn)行創(chuàng)建。

//抽象類

class ISplitter{

public:

virtual void split()=0;

virtual ISplitter* clone()=0; //通過(guò)克隆自己來(lái)創(chuàng)建對(duì)象

virtual ~ISplitter(){}

};

//具體類,直接利用拷貝構(gòu)造函數(shù)進(jìn)行配置

class BinarySplitter : public ISplitter{

public:

virtual ISplitter* clone(){

return new BinarySplitter(*this);

}

};

但是這種情況下,用戶需要手動(dòng)搭配DBConnection,DataReader存在用戶錯(cuò)誤的把不同類型的操作拼到一起的問(wèn)題。

在使用這個(gè)抽象的時(shí)候,如下面的例子。 必須強(qiáng)調(diào)原型對(duì)象盡管已經(jīng)存在了,但是它不是用來(lái)更改的,只能用來(lái)復(fù)制。 (否則不同的操作之間就可能產(chǎn)生影響,相當(dāng)于原型有了初值。 )

class MainForm : public Form

{

ISplitter* prototype;//原型對(duì)象

public:

MainForm(ISplitter* prototype){

this->prototype=prototype; //讓原型對(duì)象指向傳過(guò)來(lái)的原型

}

? ? void Button1_Click(){

? ? ISplitter * splitter=

prototype->clone(); //克隆原型

splitter->split();

}

上課內(nèi)容摘要

A. 工廠模式(Factory Method)

動(dòng)機(jī)在軟件系統(tǒng)中,經(jīng)常面臨著創(chuàng)建對(duì)象的工作;由于需求的變化,需要?jiǎng)?chuàng)建的對(duì)象的具體類型經(jīng)常變化。 如何應(yīng)對(duì)這種變化? 如何繞過(guò)常規(guī)的對(duì)象創(chuàng)建方法(new),提供一種“封裝機(jī)制”來(lái)避免客戶程序和這種“具體對(duì)象創(chuàng)建工作”的緊耦合?

模式定義

結(jié)構(gòu)

要點(diǎn)總結(jié)

B. 抽象工廠(Abstract Factory)

動(dòng)機(jī)在軟件系統(tǒng)中,經(jīng)常面臨著“一系列相互依賴的對(duì)象”的創(chuàng)建工作;同時(shí),由于需求的變化,往往存在更多系列對(duì)象的創(chuàng)建工作。 如何應(yīng)對(duì)這種變化? 如何繞過(guò)常規(guī)的對(duì)象創(chuàng)建方法(new),提供一種“封裝機(jī)制”來(lái)避免客戶程序和這種“多系列具體對(duì)象創(chuàng)建工作”的緊耦合?

模式定義

結(jié)構(gòu)

要點(diǎn)總結(jié)

C. 原型模式(Prototype)

動(dòng)機(jī)在軟件系統(tǒng)中,經(jīng)常面臨著“某些結(jié)構(gòu)復(fù)雜的對(duì)象”的創(chuàng)建工作;由于需求的變化,這些對(duì)象經(jīng)常面臨著劇烈的變化,但是它們卻擁有比較穩(wěn)定一致的接口。 如何應(yīng)對(duì)這種變化? 如何向“客戶程序(使用這些對(duì)象的程序)”隔離出“這些易變對(duì)象”,從而使得“依賴這些易變對(duì)象的客戶程序”不隨著需求改變而改變?

模式定義

結(jié)構(gòu)

要點(diǎn)總結(jié)

D. 構(gòu)建器(Builder)

動(dòng)機(jī)在軟件系統(tǒng)中,有時(shí)候面臨著“一個(gè)復(fù)雜對(duì)象”的創(chuàng)建工作其通常由各個(gè)部分的子對(duì)象用一定的算法構(gòu)成;由于需求的變化,這個(gè)復(fù)雜對(duì)象的各個(gè)部分經(jīng)常面臨著劇烈的變化,但是它們組合在一起的算法卻相對(duì)穩(wěn)定。 如何應(yīng)對(duì)這種變化? 如何提供一種“封裝機(jī)制”來(lái)隔離出“復(fù)雜對(duì)象的各個(gè)部分”的變化,從而保持系統(tǒng)中的“穩(wěn)定構(gòu)建算法”不隨著需求改變而改變?

模式定義

結(jié)構(gòu)

要點(diǎn)總結(jié)

“接口隔離”模式

在組件構(gòu)建過(guò)程中,某些接口之間直接的依賴常常會(huì)帶來(lái)很多問(wèn)題,甚至根本無(wú)法實(shí)現(xiàn)。 采用添加一層間接(穩(wěn)定)接口,來(lái)隔離本來(lái)互相緊密關(guān)聯(lián)的接口是一種常見的解決方案。

A. 門面模式(Facade)

動(dòng)機(jī)組件的客戶和組件中各種復(fù)雜的子系統(tǒng)有了過(guò)多的耦合,隨著外部客戶程序和各子系統(tǒng)的演化,這種過(guò)多的耦合面臨很多變化的挑戰(zhàn)。 如何簡(jiǎn)化外部客戶程序和系統(tǒng)間的交互接口? 如何將外部客戶程序的演化和內(nèi)部子系統(tǒng)的變化之間的依賴相互解耦?

模式定義

結(jié)構(gòu)

要點(diǎn)總結(jié)

B. 代理模式(Proxy)

動(dòng)機(jī)在面向?qū)ο笙到y(tǒng)中,有些對(duì)象由于某種原因(比如對(duì)象創(chuàng)建的開銷很大,或者某些操作需要安全控制,或者需要進(jìn)程外的訪問(wèn)等),直接訪問(wèn)會(huì)給使用者、或者系統(tǒng)結(jié)構(gòu)帶來(lái)很多麻煩。 如何在不失去透明要求操作對(duì)象的同時(shí)來(lái)管理/控制這些對(duì)象特有的復(fù)雜性? 增加一層間接層是軟件開發(fā)中常見的解決方式。

模式定義

結(jié)構(gòu)

要點(diǎn)總結(jié)

C. 適配器(Adapter)

動(dòng)機(jī)在軟件系統(tǒng)中,由于應(yīng)用環(huán)境的變化,常常需要將“一些現(xiàn)存的對(duì)象”放在新的環(huán)境中應(yīng)用,但是新環(huán)境要求的接口是這些現(xiàn)存對(duì)象所不滿足的。 如何應(yīng)對(duì)這種“遷移的變化”? 如何既能利用現(xiàn)有對(duì)象的良好實(shí)現(xiàn),同時(shí)又能滿足新的應(yīng)用環(huán)境所要求的接口?

模式定義

結(jié)構(gòu)

要點(diǎn)總結(jié)

D. 中介者(Mediator)

-動(dòng)機(jī)在軟件構(gòu)建過(guò)程中,經(jīng)常會(huì)出現(xiàn)多個(gè)對(duì)象互相關(guān)聯(lián)交互的情況,對(duì)象之間常常會(huì)維持一種復(fù)雜的引用關(guān)系,如果遇到一些需求的更改,這種直接的引用關(guān)系將面臨不斷的變化。 這種情況下,我們可使用一個(gè)“中介對(duì)象”來(lái)管理對(duì)象間的關(guān)聯(lián)關(guān)系,避免相互交互的對(duì)象之間的緊耦合引用關(guān)系,從而更好地抵御變化。

模式定義

結(jié)構(gòu)

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容