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