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