[譯者按] 本文根據發表在CUJ Expert Forum上的兩篇文章編譯而成。C/C++ User's Journal是目前最出色的C/C++語言專業雜誌，特別是在C++ Report閉刊之後，CUJ的地位更加突出。CUJ Expert Forum是CUJ主辦的網上技術專欄，彙集2000年10月以來C++社羣中頂尖專家的技術短文，並免費公開發布，精彩紛呈，是每一個C/C++學習者不可錯過的資料。由Jim Hyslop和Herb Sutter主持的Conversation系列，是CUJ Expert Forum每期必備的精品專欄，以風趣幽默的對話形式講解C++高級技術，在C++社羣內得到廣泛讚譽。譯者特別挑選兩篇設計模式方面的文章，介紹給大家。設計模式方面的經典著作是GoF的Design Patterns。但是那本書有一個缺點，不好懂。從風格上講，該書與其說是爲學習者而寫作的教程範本，還不如說是給學術界人士看的學術報告，嚴謹有餘，生動不足。這一點包括該書作者和象Bjarne Stroustrup這樣的大師都從不諱言。實際上Design Pattern並非一定是晦澀難懂的，通過生動的例子，一箇中等水平的C++學習者完全可以掌握基本用法，在自己的編程實踐中使用，得到立竿見影的功效。這兩篇文章就是很好的例證。本文翻譯在保證技術完整性的前提下作了不少刪節和修改，以便使文章顯得更緊湊。
----------------------------------------------------------
人物介紹：
我 --- 一個追求上進的C++程序員，尚在試用期，聰明但是經驗不足。
Wendy --- 公司裏的技術大拿，就坐在我旁邊的隔間裏，C++大蝦，最了不起的是，她是個女的！她什麼都好，就是有點刻薄，
我對她真是又崇拜又嫉妒。
----------------------------------------------------------
I. Virtually Yours -- Template Method模式
我在研究Wendy寫的一個類。那是她爲這個項目寫的一個抽象基類，而我的工作就是從中派生出一個具象類(concrete class)。這個類的public部分是這樣的：
class Mountie {
public:
void read( std::istream & );
void write( std::ostream & ) const;
virtual ~Mountie();
很正常，virtual destructor表明這個類打算被繼承。那麼再看看其protected部分：
protected:
virtual void do_read( std::istream & );
virtual void do_write( std::ostream & ) const;
也不過就是一會兒的功夫，我識破了Wendy的把戲：她在使用template method模式。public成員函數read和write是非虛擬的，它們肯定是調用protected部分do_read/do_write虛擬成員函數來完成實際的工作。啊，我簡直爲自己的進步而飄飄然了！哈，Wendy，這回你可難不住我，還有什麼招數？儘管放馬過來... 突然，笑容在我臉上凝固，因爲我看到了其private部分：
private:
virtual std::string classID() const = 0;
這是什麼？一個private純序函數，能工作麼？我站了起來，
“Wendy，你的Mountie類好像不能工作耶，它有一個private virtual function。”
“你試過了？”她連頭都不擡。
“嗯，那倒是沒有啦，可是想想也不行啊？我的派生類怎麼能override你的private函數呢？” 我嘟囔着。
“嗬，你倒是很確定啊！”Wendy的聲音很輕柔，“你怎麼老是這也不行，那也不行的，這幾個月跟着我你就沒學到什麼東西嗎？小菜鳥。”
真是可惡啊...
“小菜鳥，你全都忘了，訪問控制級別跟一個函數是不是虛擬的根本沒關係。判斷一個函數是動態綁定還是靜態綁定是函數調用解析的最後一個步驟。好好讀讀標準的3.4和5.2.2節吧。”
我完全處於下風，只好採取干擾戰術。“好吧，就算你說的不錯，我也還是不明白，何必把它設爲private？”
“我且問你，倘若你不想讓一個類中的成員函數被其他的類調用，應當如何處理？”
“當然是把它設置爲private的，” 我回答道。
“那麼你去看看我的Mountie類實現，特別是write()函數的實現。”
我正巴不得逃開Wendy那刺人的目光，便轉過頭去在我的屏幕上搜索，很快，我找到了：
void Mountie::write(std::ostream &Dudley) const
{
Dudley << classID() << std::endl;
do_write(Dudley);
}
嗨，最近卡通片真是看得太多了，居然犯這樣的低級失誤。還是老是承認吧：“好了，我明白了。classID()是一個實現細節，用來在保存對象時指示具象類的類型，派生類必須覆蓋它，所以必須是純虛的。但是既然是實現細節，就應該設爲private的。”
“這還差不多，小菜鳥。”大蝦點了點頭，“現在給我解釋一下爲什麼do_read()和do_write()是protected的？”
這個問題並不難，我組織了一下就回答：“因爲派生類對象需要調用這兩個函數的實現來讀寫其中的基類對象。”
“很好很好，”大蝦差不多滿意了，“不過，你再解釋解釋爲什麼我不把它們設爲public的？”
現在我感覺好多了：“因爲調用它們的時候必須以一種特定的方式進行。比如do_write()函數，必須先把類型信息寫入，再把對象信息寫入，這樣讀取的時候，負責生成對象的模塊首先能夠知道要讀出來的對象是什麼類型的，然後才能正確地從流中讀取對象信息。”
“聰明啊，我的小菜鳥！”Wendy停頓了一下，“就跟學習外國口語一樣，學習C++也不光是掌握語法而已，還必須要掌握大量的慣用法。”
“是啊是啊，我正打算讀Coplien的書...”
[譯者注：就是James Coplien 1992年的經典著作Advanced C++ Programming Style and Idioms]
大蝦揮了揮她的手，“冷靜，小菜鳥，我不是指先知Coplien的那本書，我是指某種結構背後隱含的慣用法。比如一個類有virtual destructor，相當於告訴你說：‘嗨，我是一個多態基類，來繼承我吧！’ 而如果一個類的destructor不是虛擬的，則相當於是在說：‘我不能作爲多態基類，看在老天的份上，別繼承我。’”
“同樣的，virtual函數的訪問控制級別也具有隱含的意義。一個protected virtual function告訴你：‘你寫的派生類應該，哦，可是說是必須調用我的實現。’而一個private virtual function是在說：‘派生類可以覆蓋，也可以不覆蓋我，隨你的便。但是你不可以調用我的實現。’”
我點點頭，告訴她我懂了，然後追問道：“那麼public virtual function呢？”
“儘可能不要使用public virtual function。”她拿起一支筆寫下了以下代碼：
class HardToExtend
{
public:
virtual void f();
};
void HardToExtend::f()
{
// Perform a specific action
}
“假設你發佈了這個類。在寫第二版時，需求有所變化，你必須改用Template Method。可是這根本不可能，你知道爲什麼？”
“呃，這個...，不知道。”
“由兩種可能的辦法。其一，將f()的實現代碼轉移到一個新的函數中，然後將f()本身設爲non-virtual的：
class HardToExtend
{
// possibly protected
virtual void do_f();
public:
void f();
};
void HardToExtend::f()
{
// pre-processing
do_f();
// post-processing
}
void HardToExtend::do_f()
{
// Perform a specific action
}
然而你原來寫的派生類都是企圖override函數f()而不是do_f()的，你必須改變所有的派生類實現，只要你錯過了一個類，你的類層次就會染上先知Meyers所說的‘精神分裂的行徑’。” [譯者注：參見Scott Meyers，Effective C++, Item 37，絕對不要重新定義繼承而來的非虛擬函數]
“另一種辦法是將f()移到private區域，引入一個新的non-virtual函數：”
class HardToExtend
{
// possibly protected
virtual void f();
public:
void call_f();
};
“這會導致無數令人頭痛的問題。首先，所有的客戶都企圖調用f()而不是call_f()，現在它們的代碼都不能編譯了。更有甚者，大部分派生類都回把f()放在public區域中，這樣直接使用派生類的用戶可以訪問到你本來想保護的細節。”
“對待虛函數要象對待數據成員一樣，把它們設爲private的，直到設計上要求使用更寬鬆的訪問控制再來調整。要知道由private入public易，由public入private難啊！”
[譯者注：這篇文章所表達的思想具有一定的顛覆性，因爲我們太容易在基類中設置public virtual function了，Java中甚至專門爲這種做法建立了interface機制，現在竟然說這不好！一時間真是接受不了。但是仔細體會作者的意思，他並不是一般地反對public virtual function，只是在template method大背景下給出上述原則。雖然這個原則在一般的設計中也是值得考慮的，但是主要的應用領域還是在template method模式中。當然，template method是一種非常有用和常用的模式，因此也決定了本文提出的原則具有廣泛的意義。]
----------------------------------------------------------------
II. Visitor模式
我正在爲一個設計問題苦惱。試用期快結束了，我希望自己解決這個問題，來證明自己的進步。每個人都記得自己的第一份工作吧，也都應該知道在這個時候把活兒做好是多麼的重要！我親眼看到其他的新僱員沒有過完試用期就被炒了魷魚，就是因爲他們不懂得如何對付那個大蝦...，別誤會，我不是說她不好，她是我見過最棒的程序員，可就是有點刻薄古怪...。現在我拜她爲師，不爲別的，就是因爲我十分希望能達到她那個高度。
我想在一個類層次(class hierarchy)中增加一個新的虛函數，但是這個類層次是由另外一幫人維護的，其他人碰都不能碰：
class Personnel
{
public:
virtual void Pay ( ) = 0;
virtual void Promote( ) = 0;
virtual void Accept ( PersonnelV& ) = 0;
// ... other functions ...
};
class Officer : public Personnel {};
class Captain : public Officer {};
class First : public Officer {};
我想要一個函數，如果對象是船長(Captain)就這麼做，如果是大副(First Officer)就那麼做。Virtual function正是解決之道，在Personnel或者Officer中聲明它，而在Captain和First覆蓋(override)它。
糟糕的是，我不能增加這麼一個虛函數。我知道可以用RTTI給出一個解決方案：
void f( Officer &o )
{
if( dynamic_cast<Captain*>(&o) )
else if( dynamic_cast<First*>(&o) )
}
int main()
{
Captain k;
First s;
f( k );
f( s );
}
但是我知道使用RTTI是公司編碼標準所排斥的行爲，我對自己說：“是的，雖然我以前不喜歡RTTI，但是這回我得改變對它的看法了。很顯然，除了使用RTTI，別無它法。”
“任何問題都可以通過增加間接層次的方法解決。”
我噌地一下跳起來，那是大蝦的聲音，她不知道什麼時候跑到我背後，“啊喲，您嚇了我一跳...您剛纔說什麼？”
“任何問...”
“是的，我聽清楚了，”我也不知道哪來的勇氣，居然敢打斷她，“我只是不知道您從哪冒出來的。”其實這話只不過是掩飾我內心的慌張。
“哈，算了吧，小菜鳥，”大蝦斜着眼看着我，“你以爲我不知道你心裏想什麼！”她把聲音提高了八度，直盯着我，“那些可憐的C語言門徒纔會使用switch語句處理不同的對象類型。你看：”
void f(struct someStruct *s)
{
switch(s->type) {
case APPLE:
break;
case ORANGE:
break;
}
}
“這些人學習Stroustrup教主的C++語言時，最重要的事情就是學習如何設計好的類層次。”
“沒錯，”我又一次打斷她，迫不及待地想讓Wendy明白，我還是有兩下子的，“他們應該設計一個Fruit基類，派生出Apple和Orange，用virtual function來作具體的事情。
“很好，小菜鳥。C語言門徒通常老習慣改不掉。但是，你應該知道，通過使用virtual function，你增加了一個間接層次。”她放下筆，“你所需要的不就是一個新的虛函數嗎？”
“是的。可是我沒有權力這麼幹。”
“因爲你無權修改類層次，對吧！”
“您終於瞭解了情況，我們沒法動它。也不知道這個該死的類層次是哪個傢伙設計的...” 我嘀嘀咕咕着。
“是我設計的。”
“啊...，真的？！這個，嘿嘿...”，我極爲尷尬。
“這個類層次必須非常穩定，因爲有跨平臺的問題。但是它的設計允許你增加新的virtual function，而不必煩勞RTTI。你可以通過增加一個間接層次的辦法解決這個問題。請問，Personnel::Accept是什麼”
”嗯，這個...”
“這個類實現了一個模式，可惜這個模式的名字起得不太好，是個PNP，叫Visitor模式。”
[譯者注：PNP，Poor-Named Pattern, 沒起好名字的模式]
“啊，我剛剛讀過Visitor模式。但是那只不過是允許若干對象之間相互迭代訪問的模式，不是嗎？”
她嘆了一口氣，“這是流行的錯誤理解。那個V，我覺得毋寧說是Visitor，還不如說是Virtual更好。這個PNP最重要的用途是允許在不改變類層次的前提下，向已經存在的類層次中增加新的虛函數。首先來看看Personnel及其派生類的Accept實現細節。”她拿起筆寫下：
void Personnel::Accept( PersonnelV& v )
{v.Visit( *this );}
void Officer::Accept ( PersonnelV& v )
{v.Visit( *this );}
void Captain::Accept ( PersonnelV& v )
{v.Visit( *this );}
void First::Accept ( PersonnelV& v )
{v.Visit( *this );}
“Visitor的基類如下：”
class PersonnelV
{
public:
virtual void Visit( Personnel& ) = 0;
virtual void Visit( Officer& ) = 0;
virtual void Visit( Captain& ) = 0;
virtual void Visit( First& ) = 0;
};
“啊，我記起來了。當我要利用Personnel類層次的多態性時，我只要調用Personnel::Accept(myVisitorObject)。由於Accept是虛函數，我的myVisitorObject.Visit()會針對正確的對象類型調用，根據重載法則，編譯器會挑選最貼切的那個Visit來調用。這不相當於增加了一個新的虛擬函數了嗎？”
“沒錯，小菜鳥。只要類層次支持Accept，我們就可以在不改動類層次的情況下增加新的虛函數了。”
“好了，我現在知道該怎麼辦了”，我寫道：
class DoSomething : public PersonnelV
{
public:
virtual void Visit( Personnel& );
virtual void Visit( Officer& );
virtual void Visit( Captain& );
virtual void Visit( First& );
};
void DoSomething::Visit( Captain& c )
{
if( femaleGuestStarIsPresent )
c.TurnOnCharm();
else
c.StartFight();
}
void DoSomething::Visit( First& f )
{
f.RaiseEyebrowAtCaptainsBehavior();
}
void f( Personnel& p )
{
p.Accept( DoSomething() ); // 相當於 p.DoSomething()
}
int main()
{
Captain k;
First s;
f( k );
f( s );
}
大蝦滿意地笑了，“也許這個模式換一個名字會更好理解，可惜世事往往不遂人意...”。