從實(shí)現(xiàn)裝飾者模式中思考C++指針和引用的選擇
最近在看設(shè)計(jì)模式的內(nèi)容，偶然間手癢就寫了一個(gè)“裝飾者”模式的一個(gè)實(shí)例。該實(shí)例來源于風(fēng)雪漣漪的博客，我對(duì)它做了簡(jiǎn)化。作為一個(gè)經(jīng)典的設(shè)計(jì)模式，本身并沒有太多要說的內(nèi)容。但是在我嘗試使用C++去實(shí)現(xiàn)這個(gè)模式的實(shí)例的時(shí)候，出現(xiàn)了一些看似無關(guān)緊要但是卻引人深思的問題。
首先，我想簡(jiǎn)單介紹一下這個(gè)實(shí)例的含義。實(shí)例的目的是希望通過裝飾器類對(duì)已有的蛋糕類進(jìn)行裝飾補(bǔ)充，于是按照裝飾者模式的設(shè)計(jì)結(jié)構(gòu)，有類似圖1的設(shè)計(jì)結(jié)構(gòu)。
計(jì)模式/裝飾者.jpg)
圖1 裝飾者模式
蛋糕類和裝飾器類都繼承于一個(gè)公共的基類，該基類聲明了一些公共接口。這里簡(jiǎn)單的使用getName來返回當(dāng)前蛋糕的名稱，而裝飾器類可以對(duì)該蛋糕的名稱進(jìn)行修改補(bǔ)充。具體的蛋糕類都有自己的名稱，比如CheeseCake返回的是“奶油蛋糕”。如果使用了裝飾器類對(duì)該類進(jìn)行裝飾的話，返回的名字就發(fā)生了的變化，比如“裝飾了花的奶油蛋糕”，這正是裝飾器類的功能。實(shí)現(xiàn)這個(gè)功能的關(guān)鍵在于裝飾器公共基類Decorator，它包含了一個(gè)Cake類型的成員cake。在定義裝飾器的時(shí)候我們可以傳遞給裝飾器一個(gè)已經(jīng)建立好的蛋糕對(duì)象，比如CheeseCake對(duì)象。由于CheeseCake是Cake的子類，因此該對(duì)象可以被cake成員記錄下來。由于具體的裝飾器繼承于裝飾器基類Decorator，因此保護(hù)乘員cake可以被看到，又因?yàn)檠b飾器本身也是繼承與Cake的，因此也擁有getName的接口，這樣在裝飾器類內(nèi)用getName調(diào)用cake的getName接口并添加額外的操作就能完成裝飾的目的。另外，裝飾器本身也是Cake的子類，因此裝飾后的裝飾器類對(duì)象同時(shí)也是一個(gè)具體的蛋糕對(duì)象，它可以被再次裝飾！這樣裝飾器類反映在我們腦海里的情境就是一個(gè)原本的蛋糕對(duì)象外邊包裹了一層層裝飾器對(duì)象。
以上的說明如果還不夠清楚的話，下邊展示具體的實(shí)現(xiàn)代碼。這里就需要考慮cake成員的類型問題，一般使用指針類型可能更符合C++的編程習(xí)慣。因?yàn)槭褂脤?duì)象不僅消耗空間，還在每次構(gòu)造對(duì)象的時(shí)候進(jìn)行對(duì)象的復(fù)制，這都不是我們?cè)敢饪吹降?。?dāng)然，使用引用或許更合理，因?yàn)榘凑掌匠５慕?jīng)驗(yàn)，很多使用C++指針的地方都可以用引用代替，有人甚至建議多使用引用少使用指針（當(dāng)然我也承認(rèn)C++引用也有很多好處~）。不過，當(dāng)你讀完本文或許你就不大這么認(rèn)為了。首先，我們用Cake*pCake實(shí)現(xiàn)這個(gè)裝飾器類內(nèi)的成員，先具體了解一下這個(gè)代碼的具體內(nèi)容。
按 Ctrl+C 復(fù)制代碼
按 Ctrl+C 復(fù)制代碼
從代碼中不難看出程序的輸出結(jié)構(gòu)應(yīng)該是“裝飾過花的裝飾過花的奶油蛋糕”，事實(shí)也的確如此！從裝飾器的使用格式來看FlowerDecorator(&FlowerDecorator(&CheeseCake()))倒也不至于十分麻煩。但是剛才討論過，如果能使用引用代替會(huì)許會(huì)更“舒服”，至少不用傳遞參數(shù)之前還要使用&獲取一下地址了~
既然如此，我們把成員修改為引用格式的：
#pragma once
#include <iostream>
using namespace std;
//Cake公共基類，提供裝飾者和被裝飾物的統(tǒng)一接口
class Cake
{
public:
virtual string getName()const=0;
};
//一個(gè)具體的蛋糕
class CheeseCake:public Cake
{
public:
virtual string getName()const
{
return string("奶油蛋糕");
}
};
//一個(gè)裝飾者基類
class Decorator:public Cake
{
protected:
Cake &pCake;
public:
Decorator(Cake&pc):pCake(pc){}
};
//一個(gè)具體的裝飾器
class FlowerDecorator:public Decorator
{
public:
FlowerDecorator(Cake&pc):Decorator(pc){}
virtual string getName()const
{
string decName="裝飾過花的";
decName+=pCake.getName();
return decName;
}
};
int main()
{
cout<<
FlowerDecorator(
FlowerDecorator(
CheeseCake()
))
.getName().c_str()
<<endl;
return 0;
}
修改后的代碼看起來的確更“順眼了”。因?yàn)檎{(diào)用的時(shí)候我們不用再寫那個(gè)看著別扭的取地址運(yùn)算符了，然后我們滿懷欣喜的執(zhí)行了程序，輸出結(jié)果為：“裝飾過花的奶油蛋糕”！你我的第一反應(yīng)八成是覺得忘了多修飾一次了，但是我們認(rèn)真的檢查代碼，發(fā)現(xiàn)的確一切都是符合邏輯的……
上邊做了這么多鋪墊就是為了引出這個(gè)奇怪的問題，我其實(shí)也被該問題困惑了很久。稍有編程經(jīng)驗(yàn)的人都會(huì)跟蹤調(diào)試這些構(gòu)造函數(shù)的執(zhí)行過程，結(jié)果發(fā)現(xiàn)FlowerDecorator只被執(zhí)行了一次，因此少輸出一次“裝飾過花的”不足為奇。但是你我肯定好奇為什么會(huì)少輸出一次呢？
再次再次的檢查代碼、調(diào)試、跟蹤，或許你會(huì)像發(fā)現(xiàn)新大陸一樣發(fā)現(xiàn)了一個(gè)隱藏的問題：第二次構(gòu)造FlowerDecorator時(shí)調(diào)用的是復(fù)制構(gòu)造函數(shù)，而不是定義好的構(gòu)造函數(shù)（雖然子類FlowerDecorator是Cake的子類，但是編譯器會(huì)自動(dòng)最佳匹配函數(shù)參數(shù)類型）！由于復(fù)制構(gòu)造函數(shù)值原模原樣的拷貝出一個(gè)對(duì)象，所以只能完成一次裝飾器裝飾。非常完美的解釋！因此我們可以自己重寫復(fù)制構(gòu)造函數(shù)來完成我們的裝飾功能，這里先忽略原本的對(duì)象復(fù)制功能了。編譯器為我們生成的復(fù)制構(gòu)造函數(shù)應(yīng)該是：
FlowerDecorator(const FlowerDecorator&pc):Decorator(pc.pCake){}
而我們應(yīng)該將參數(shù)看作一個(gè)Cake對(duì)象進(jìn)行裝飾，因此修改為：
FlowerDecorator(const FlowerDecorator&pc):Decorator(const_cast<FlowerDecorator&>(pc)){}
同樣，由于構(gòu)造函數(shù)初始化了基類，所以基類的復(fù)制構(gòu)造也需要重寫：
Decorator(const Decorator&pc):pCake(const_cast<Decorator&>(pc)){}
即使傳遞的參數(shù)是FlowerDecorator對(duì)象和Cake與Decorator不是一個(gè)類型，但是編譯器或許默認(rèn)的匹配繼承層次最近的類型！然后我們按照這樣要求重寫了代碼，執(zhí)行了程序，在期待結(jié)果的那一刻看到的是“裝飾過花的奶油蛋糕”……或許此時(shí)的你都會(huì)感到灰心，但是你還是依然的堅(jiān)強(qiáng)的按下了F5單步跟蹤，結(jié)果你發(fā)現(xiàn)拷貝構(gòu)造函數(shù)并沒有被調(diào)用！難道以上的假設(shè)都錯(cuò)了嗎？我可以確定的告訴讀者，我們以上的假設(shè)都是正確的。
最終我也是沒有辦法，去StackOverFlow上求助，綜合回答者的討論，我終于把問題的原因鎖定了——編譯器優(yōu)化！我覺得用一個(gè)最簡(jiǎn)單的例子來說明這個(gè)問題再合適不過了：
class A
{
public:
A(int)
{
cout<<"構(gòu)造\n";
}
A(const A&)
{
cout<<"拷貝\n";
}
};
int main()
{
A(0);
cout<<"------------------------\n";
A(A(0));
cout<<"------------------------\n";
A(A(A(0)));
cout<<"------------------------\n";
A(A(A(A(0))));
cout<<"------------------------\n";
A(A(A(A(A(0)))));
cout<<"------------------------\n";
return 0;
}
這個(gè)簡(jiǎn)單的例子結(jié)果或許大家都很明白，但是你親自測(cè)試一下就可能要懷疑自己的判斷能力了，程序輸出：
造函數(shù)windows.jpg)
是不是有點(diǎn)世界觀被顛覆的感覺？需要聲明一下，這個(gè)是Visual Studio 2010下的測(cè)試結(jié)果，因?yàn)檫@個(gè)程序的輸出的確和編譯器相關(guān)！為了確認(rèn)我用gcc-4.4.3測(cè)試了該段代碼，輸出結(jié)果為：
造函數(shù)linux.jpg)
看來，還是gcc優(yōu)化的比較徹底。因此我們可以得出結(jié)論，類似這種無名對(duì)象的構(gòu)造（有名的是按照規(guī)矩來的），調(diào)用多少次構(gòu)造函數(shù)要看編譯器的“脾氣”了。到這里，不知道你對(duì)引用參數(shù)的感覺如何？
討論到這，或許有人說和本來要討論的話題離得太遠(yuǎn)了。其實(shí)并不是，佛家說：“今日之果皆來自昨日之因”，一切的一切都是由于我們使用了本以為毫無懸念的引用導(dǎo)致的！如果使用指針就不可能發(fā)生和拷貝構(gòu)造函數(shù)沖突的問題，也不會(huì)導(dǎo)致編譯器優(yōu)化的問題！回視本文剛開始舉的例子和該文的主題，或許我們應(yīng)該清楚有時(shí)候的確要好好區(qū)分一下指針和引用的差別了，當(dāng)然本文也是從一個(gè)實(shí)踐的例子中去發(fā)現(xiàn)和挖掘這一點(diǎn)。