C++設(shè)計(jì)模式之橋接模式
問題描述
現(xiàn)在要去畫一個(gè)圖形,圖形有長(zhǎng)方形、圓形和扇形等等;而圖形又可以加上不同的顏色,然后,我們就可以畫出紅色的長(zhǎng)方形,綠色的長(zhǎng)方形;紅色的圓形,綠色的圓形等等。而這種圖形的形狀在變化,圖形的顏色也在變化,當(dāng)使用代碼去實(shí)現(xiàn)時(shí),如何面對(duì)這種多方面的變化呢?這就要說到今天的橋接模式了。
什么是橋接模式?
對(duì)于上述的圖形與顏色的問題時(shí),很多時(shí)候,我們讓各個(gè)圖形類繼承顏色類,比如:
class CShape
{
};
class CRectangle : public CShape
{
};
class CCircle : public CShape
{
};
class CColor
{
};
class CRed : public CColor
{
};
class CBlue : public CColor
{
};
class CRedRectangle : public CRed
{
};
class CBlueRectangle : public CBlue
{
};
每當(dāng)我們?cè)黾右粋€(gè)新的圖形,或者增加一種新的顏色時(shí),對(duì)應(yīng)的類就會(huì)以相乘的速度進(jìn)行增加。當(dāng)系統(tǒng)中的類變的多時(shí),對(duì)應(yīng)的管理也就變的復(fù)雜,這不是我們希望看到的。同時(shí),我們可以看到CRedRectangle類繼承自CRed類,這種繼承關(guān)系合理嗎?且不說有的系統(tǒng)是如此實(shí)現(xiàn)的,紅色的矩形是紅色嗎?很顯然,CRedRectangle和CRed之間不是一種is-a的關(guān)系,所以,上面的實(shí)現(xiàn)是及其不合理的。那么它們是什么關(guān)系呢?接著往下看。
在GOF的《設(shè)計(jì)模式:可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書中對(duì)橋接模式是這樣說的:將抽象部分和它的實(shí)現(xiàn)部分分離,使它們都可以獨(dú)立的變化。簡(jiǎn)單粗暴的說,就是抽象對(duì)外提供調(diào)用的接口;對(duì)外隱瞞實(shí)現(xiàn)部分,在抽象中引用實(shí)現(xiàn)部分,從而實(shí)現(xiàn)抽象對(duì)實(shí)現(xiàn)部分的調(diào)用,而抽象中引用的實(shí)現(xiàn)部分可以在今后的開發(fā)過程中,切換成別的實(shí)現(xiàn)部分。
為什么要使用橋接模式?
當(dāng)一個(gè)抽象可能有多個(gè)實(shí)現(xiàn)時(shí),通常用繼承來協(xié)調(diào)它們。抽象類定義對(duì)該抽象的接口,而具體的子類則用不同方式加以實(shí)現(xiàn)。但是此方法有時(shí)不夠靈活。繼承機(jī)制將抽象部分與它的實(shí)現(xiàn)部分固定在一起,使得難以對(duì)抽象部分和實(shí)現(xiàn)部分獨(dú)立的進(jìn)行修改、擴(kuò)充和重用。橋接模式把依賴具體實(shí)現(xiàn),提升為依賴抽象,來完成對(duì)象和變化因素之間的低耦合,提高系統(tǒng)的可維護(hù)性和擴(kuò)展性。橋接模式的主要目的是將一個(gè)對(duì)象的變化與其它變化隔離開,讓彼此之間的耦合度最低。
什么時(shí)候使用橋接模式?
1.如果不希望在抽象和它的實(shí)現(xiàn)部分之間有一個(gè)固定的綁定關(guān)系,也就是繼承關(guān)系;如果我們打破了這種固定的綁定關(guān)系,以后,就可以方便的在抽象部分切換不同的實(shí)現(xiàn)部分;
2.如果希望類的抽象以及它的實(shí)現(xiàn)都應(yīng)該可以通過生成子類的方法加以擴(kuò)充;如果不使用橋接模式,使用繼承去實(shí)現(xiàn)時(shí),在抽象類中添加一個(gè)方法,則在對(duì)應(yīng)的實(shí)現(xiàn)類中也需要做對(duì)應(yīng)的改動(dòng),這種實(shí)現(xiàn)不符合松耦合的要求;
3.如果要求對(duì)一個(gè)抽象的實(shí)現(xiàn)部分的修改對(duì)客戶不產(chǎn)生影響,即客戶的代碼不需要重新編譯,在后面的項(xiàng)目經(jīng)驗(yàn)會(huì)說這方面;
4.如果想對(duì)客戶完全隱藏抽象的實(shí)現(xiàn)部分;
5.如果一個(gè)對(duì)象有多個(gè)變化因素的時(shí)候,通過抽象這些變化因素,將依賴具體實(shí)現(xiàn),修改為依賴抽象;
6.如果某個(gè)變化因素在多個(gè)對(duì)象中共享時(shí),可以抽象出這個(gè)變化因素,然后實(shí)現(xiàn)這些不同的變化因素。
上面使用的場(chǎng)景,是一種建議,也是一種參考。在項(xiàng)目中要很好的把握一個(gè)設(shè)計(jì)模式,是有一定的難度的;當(dāng)在實(shí)際項(xiàng)目中遇到滿足上面的一點(diǎn)或者幾點(diǎn)時(shí),可以考慮使用橋接模式。
UML類圖
Abstraction類定義了抽象類的接口,并且維護(hù)一個(gè)指向Implementor實(shí)現(xiàn)類的指針;
RefineAbstraction類擴(kuò)充了Abstraction類的接口;
Implementor類定義了實(shí)現(xiàn)類的接口,這個(gè)接口不一定要與Abstraction的接口完全一致;實(shí)際上,這兩個(gè)接口可以完全不同;
ConcreteImplementor類實(shí)現(xiàn)了Implementor定義的接口。
代碼實(shí)現(xiàn)
/*
** FileName : BridgePatternDemo
** Author : Jelly Young
** Date : 2013/12/4
** Description : More information, please go to http://www.dbjr.com.cn
*/
#include <iostream>
using namespace std;
class Implementor
{
public:
virtual void OperationImpl() = 0;
};
class ConcreteImpementor : public Implementor
{
public:
void OperationImpl()
{
cout<<"OperationImpl"<<endl;
}
};
class Abstraction
{
public:
Abstraction(Implementor *pImpl) : m_pImpl(pImpl){}
virtual void Operation() = 0;
protected:
Implementor *m_pImpl;
};
class RedfinedAbstraction : public Abstraction
{
public:
RedfinedAbstraction(Implementor *pImpl) : Abstraction(pImpl){}
void Operation()
{
m_pImpl->OperationImpl();
}
};
int main(int argc, char *argv[])
{
Implementor *pImplObj = new ConcreteImpementor();
Abstraction *pAbsObj = new RedfinedAbstraction(pImplObj);
pAbsObj->Operation();
delete pImplObj;
pImplObj = NULL;
delete pAbsObj;
pAbsObj = NULL;
return 0;
}
根據(jù)對(duì)代碼的理解,能想象到CRedRectangle和CRed是什么關(guān)系嗎?我們可以理解為紅色的矩形包含紅色,也就是包含的關(guān)系,也就是軟件設(shè)計(jì)中的組合關(guān)系(has-a)。
項(xiàng)目經(jīng)驗(yàn)
這是一個(gè)我經(jīng)歷的項(xiàng)目,也是做起來比較輕松的一個(gè)項(xiàng)目。項(xiàng)目是這樣的,需要對(duì)一個(gè)中間的通信庫進(jìn)行改寫,保留以前的通信方式的同時(shí),需要使用一種新的通信協(xié)議去和底層模塊進(jìn)行通信?,F(xiàn)有的代碼是一個(gè)COM程序,向外提供了可以調(diào)用的接口。根據(jù)客戶提供的源碼,我們進(jìn)行了分析;在分析之前,我們有一種擔(dān)心,就是怕用戶的代碼是接口和實(shí)現(xiàn)混在一起的;但是,分析之后,讓我們很吃驚,客戶的代碼結(jié)構(gòu)很清晰,層次非常清楚,代碼中使用的就是我們今天這里說的橋接模式。由于抽象的接口和實(shí)現(xiàn)完全進(jìn)行了分離,我們?cè)谶M(jìn)行重寫時(shí),只需要實(shí)現(xiàn)我們的一個(gè)類,然后在接口中引用我們實(shí)現(xiàn)的類,就大功告成了,這樣做到了客戶端不需要做任何修改,就可以完美的替換掉原來的通信層,真的是前人栽樹樹,后人乘涼啊。
總結(jié)
橋接模式使得抽象和實(shí)現(xiàn)進(jìn)行了分離,抽象不用依賴于實(shí)現(xiàn),讓抽象和實(shí)現(xiàn)部分各自修改起來都很方便,使用組合(就是Abstraction類中包含了Implementor)的方式,降低了耦合度,同時(shí)也有助于分層,從而產(chǎn)生更好的結(jié)構(gòu)化系統(tǒng)。通過實(shí)際的項(xiàng)目經(jīng)驗(yàn),使用了橋接模式的代碼,對(duì)以后的擴(kuò)展有很大的幫助。
相關(guān)文章
Qt進(jìn)程和線程QProcess和QThread的使用
本文主要介紹了Qt進(jìn)程和線程QProcess和QThread的使用,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-06-06C++線性表深度解析之動(dòng)態(tài)數(shù)組與單鏈表和棧及隊(duì)列的實(shí)現(xiàn)
這篇文章主要為大家詳細(xì)介紹了C++實(shí)現(xiàn)動(dòng)態(tài)數(shù)組、單鏈表、棧、隊(duì)列,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-05-05C++中用兩個(gè)標(biāo)準(zhǔn)容器stack,實(shí)現(xiàn)一個(gè)隊(duì)列的方法詳解
本篇文章是對(duì)C++中使用兩個(gè)標(biāo)準(zhǔn)容器stack,實(shí)現(xiàn)一個(gè)隊(duì)列的方法進(jìn)行了詳細(xì)的分析介紹,需要的朋友參考下2013-05-05C++基于QWidget和QLabel實(shí)現(xiàn)圖片縮放,拉伸與拖拽
這篇文章主要為大家詳細(xì)介紹了C++如何基于QWidget和QLabel實(shí)現(xiàn)圖片縮放、拉伸與拖拽等功能,文中的示例代碼講解詳細(xì),感興趣的小伙伴可以跟隨小編一起學(xué)習(xí)一下2024-02-02