與大蝦對話: 領悟設計模式

與大蝦對話: 領悟設計模式

與大蝦對話: 領悟設計模式 與大蝦對話: 領悟設計模式

--Template Method / Visitor

[譯者按] 本文根據發表在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 { /* override virtuals */ };

class Captain : public Officer { /* override virtuals */ };

class First : public Officer { /* override virtuals */ };

我想要一個函數,如果對象是船長(Captain)就這麽做,如果是大副(First Officer)就那麽做。Virtual function正是解決之道,在Personnel或者Officer中聲明它,而在Captain和First覆蓋(override)它。

糟糕的是,我不能增加這麽一個虛函數。我知道可以用RTTI給出一個解決方案:

void f( Officer &o )

{

if( dynamic_cast<Captain*>(&o) )

/* do one thing */

else if( dynamic_cast<First*>(&o) )

/* do another thing */

}

int main()

{

Captain k;

First s;

f( k );

f( s );

}

但是我知道使用RTTI是公司編碼標准所排斥的行爲,我對自己說:「是的,雖然我以前不喜歡RTTI,但是這回我得改變對它的看法了。很顯然,除了使用RTTI,別無它法。」

「任何問題都可以通過增加間接層次的方法解決。」

我噌地一下跳起來,那是大蝦的聲音,她不知道什麽時候跑到我背後,「啊喲,您嚇了我一跳...您剛才說什麽?」

「任何問...」

「是的,我聽清楚了,」我也不知道哪來的勇氣,居然敢打斷她,「我只是不知道您從哪冒出來的。」其實這話只不過是掩飾我內心的慌張。

「哈,算了吧,小菜鳥,」大蝦斜著眼看著我,「你以爲我不知道你心裏想什麽!」她把聲音提高了八度,直盯著我,「那些可憐的C語言門徒才會使用switch語句處理不同的對象類型。你看:」

/* A not-atypical C program */

void f(struct someStruct *s)

{

switch(s->type) {

case APPLE:

/* do one thing */

break;

case ORANGE:

/* do another thing */

break;

/* ... etc. ... */

}

}

「這些人學習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/*isitor*/

{

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 );

}

大蝦滿意地笑了,「也許這個模式換一個名字會更好理解,可惜世事往往不遂人意...」。

 
與大蝦對話: 領悟設計模式
[譯者按] 本文根據發表在CUJ Expert Forum上的兩篇文章編譯而成。C/C++ User's Journal是目前最出色的C/C++語言專業雜志,特別是在C++ Report閉刊之後,CUJ的地位更加突出。CUJ Expert Forum是CUJ主辦的網上技術專欄...查看完整版>>與大蝦對話: 領悟設計模式
 
領悟設計模式
與大蝦對話: 領悟設計模式 關鍵字:Design Patterns, C++, Template Method, Visitor 編程之道翻譯者:myan 出處: http://www.cuj.com/expert --Template Method / Visitor [譯者按] 本文根據發表在CUJ Ex...查看完整版>>領悟設計模式
 
對孟岩先生翻譯的《與大蝦對話: 領悟設計模式》中的一些領悟
原文連接 設計模式:template method以下是該文中的一份示例代碼class Mountie {public: void read( std::istream & ); void write( std::ostream & ) const; virtual ~Mountie();protected: vi...查看完整版>>對孟岩先生翻譯的《與大蝦對話: 領悟設計模式》中的一些領悟
 
從完美設計中領悟生活的本質
  意大利著名的建築師厄內思托?羅傑斯中說:小到一把勺子,大到一座城市,都該是經過設計的。這句經典名言被後來的設計師們奉爲圭臬,對于如您一般的生活家而言,這何嘗又不是一種值得孜孜以求的生活理念?和設計師...查看完整版>>從完美設計中領悟生活的本質
 
獲獎作品中領悟家居設計風格
第八屆美化家居設計大賽評選結果揭曉,獲獎作品整體凸顯自然風格  在今年的美化家居展上,美化家居設計競賽的獲獎作品也是愛家人士關注的焦點之一。作爲北京市建築裝飾協會主辦、家裝委員會承辦的一項行業內的設計...查看完整版>>獲獎作品中領悟家居設計風格