避免依賴的消息處理方式

Anthony Williams
url: http://www.ddj.com/dept/cpp/184429055
譯者: Stone Jiang
譯者說明：本人還在學習英文的過程中，有些句子很難譯，這里給出原文的鏈接，歡迎就其中譯得不準確的地方與我交換意見。

在您維護安全類型和避免集成電路般函數時,你可以使用C++的強大的力量進行消息傳遞。

Anthony是Just Software Solution有限公司的一位軟件開發者和執行管理者?？梢酝ㄟ^anthony@justsoftwaresolutions.co.uk與之聯系。

使用通用的消息傳遞方式傳遞數據在C++程序中很普遍。這種技術經常用于在線程間以及從/到GUI組件間傳遞數據。但是消息傳遞仍然很難實現得良好，這是因為在常見的消息傳遞方式中，暴露出了過多的藕合、缺少類型安全和集成電路般的消息處理函數。

在本文中，我提出了一種技術，這種技術利用C++的強大力量來避免上述缺陷——在消息傳遞中避免不適當的藕合，維護類型安全，以及消除集成電路般的消息處理函。( The only translation units that need to known the details of a message are those containning the source and handler functions for that specific message type.) 需要轉換的單元，即需要知道的消息詳細內容是包含了特定消息的類型的源代碼和處理函數。

傳統技術

大概應用得最為廣泛的消息傳遞技術是使用一個帶有特殊成員來表示消息類型的結構體，該消息類型是消息的標識。這種方式被廣泛應用歸咎于使用了基于C的API，比如X11和Microsoft Windows。在這種方法中，消息結構體中要么有一個通用的字體用于區別不同消息的意義，這個字段可被所有消息重用，或者它是更大結構的第一個成員，它的類型由類型代碼來確定。Windows API使用前面的技術，而X11使用后面的方法。無論用哪種方式，處理消息的代碼都須檢查類型編碼，用以決定怎么處理該消息。

這些技術的問題是:缺乏類型安全，集成電路般的處理函數，需要管理類型編碼來確保消息唯一性的適當層次。特別的，缺乏類型安全意味著使用之前，使用代碼必須把消息數據轉換成適當的類型。這一步是極易出錯的，尤其在當復制和粘貼代碼時(這種非常的手段常發生在為處理相似消息編寫代碼的時候)，編譯器不會在這種錯誤給出任何警告。

缺乏類型安全還有一個額外的問題——即它不可能簡單有效的通過消息系統傳遞資源或變長的數據， 這是因為消息的發送方總是不能知道何時（或是否）該消息已被處理過了。

在這部分，集成電路般的消息處理函數是必須用于確定消息類型的產物，通過已接收的消息來消息類型，然后得到如何處理它的方式。這種處理函數往往實現為一個很大的switch語句或是一串if eles if。一些框架，如MFC，提供一些宏來減弱這種問題的影響，它這不能完全消除這個問題。

最后的問題是管理類型代碼。它必須要求接收消息代碼清楚地知道是哪一個消息，以便于正確的處理它。所以，類型代碼需要在處理它的相關代碼中確保唯一性。比如，在Windows API中，指定范圍的消息類型在不同的應用程序中代表不同的意義，并且，在同一個應就用程序中，其它范圍的消息類型在不同窗口或GUI組件中代表不同的意義。 通常,需要所有類型代碼的列表，該列表要求在給定的范圍中保持唯一，以便于檢查它們的唯一性。列表常常是以頭文件的形式給出，頭文件中定義了類型代碼，包含在需要知道消息類型的所有地方。這種方式容易導致應用程序不同部分之間的藕合,而這些部分之間卻沒有任何關系。由于這種過度的藕，簡單的變更導致過多的重新編譯。

面向對象技術

對象技術的一個常見特征是所有相關消息類派生自一個通用的基類。該特征用編譯器能認識的真實類型代替了顯式的類型代碼。不僅如此，它還有了一個重要的，超越C風格技術的優點——類型安全。它提供的通用基類的析構函數是虛函數，所以派生的消息類能自由地管理資源，如變長的數據，這些數據可以在析構函數中釋放。僅有的需求是接受消息的代碼能正確地銷毀消息對象，無論它們是否被處理。

管理類型代碼現在被替換為管理類。這是一個更加簡單的任務，由于可能的消息名字的范圍是沒有限制的，可能存在名字沖突，但這一點可以通過名字空間來解決。

保持簡單

最簡單的OOP技術就是用dynamic_cast檢查實際的消息類型代替檢查消息編碼。然而，這依然面臨著集成電路般地消息處理方式——現在通過包括dynamic_cast的比較鏈也優于通過類型編碼字段比較鏈。如列表1:

void ?handleMessage(Message * ?message)
{
???? if (Message1 * ?m = dynamic_cast < Message1 *> (message))
???? {
????????handleMessage1(m);
????}
???? else ? if (Message2 * ?m = dynamic_cast < Message2 *> (message))
???? {
????????handleMessage2(m);
????}
???? // ?
}

[列表1]

一般而言，由于僅僅是消息的源代碼和接受消息的源代碼需求知道相關的消息，所以依賴得到降低。然后，集成電路般地處理函數現在需要知道消息的有關細節，所以dynamic_cast需要消息的完整定義——如果分派給另外的函數處理實際的消息，C風格技術的處理函數不需求知道消息的細節。

雙重分派

(Direct testing of a class's type using dynamic_cast is generally indicative of a design problem;)類的類型用dynamic_cast的直測試一般可表示為設計問題;然而，簡單地把虛函數放在消息類中起不到任何作用——它將把消息處理與消息纏繞在一起，這個消息使在第一個地方發送消息的目的失敗。

雙重分派的關鍵點是，在消息類中的虛函數帶有一個作為參數的處理器，然后在處理器上把自已作為參數傳遞傳遞給另一個函數并完成調用。因為這里的第二次到處理器的回調已經在實際的派生類中完成，所以真實的消息類型已經知道，在處理器上能調用適當的函數，無論這個函數是通過重載的方式實現還是另外獨立命名的函數來實現(列表2)。

[列表2]

依賴于重載的方式來區別不同的消息有利于大多數平衡——現在在每個消息類中虛函數的實現方式是相同的，如果需要，可以通過宏來一致地包裝，或通過從一個消息到另一個消息中直接復制，不會有出錯的機會。

雙重分派存在一個缺點——高度藕合。由于通過重載方式在處理器類中的選擇處理函數，在消息類中虛函數的實現需要知道處理器類的定義的全部，因此必須注意到在系統中每個其它的類的名字。不光這些，如果要支持不同的處理器類，處理函數必須在通用的處理器的基類中聲明為虛函數，所以每個處理器類必須在系統中注意到所有的消息類型(列表3)。增加或刪除一個消息類型會引起應用程序大部分代碼重新編譯。

class ?MessageHandler
{
???? virtual ? void ?process(Message1 * ) = 0 ;
???? virtual ? void ?process(Message2 * ) = 0 ;
???? virtual ? void ?process(Message3 * ) = 0 ;
???? virtual ? void ?process(Message4 * ) = 0 ;
???? // ?overloads?of?process?for?other?messages
} ;
class ?SpecificMessageHandler:
???? public ?MessageHandler
{
???? void ?process(Message1 * );
???? void ?process(Message2 * );
???? void ?process(Message3 * );
???? void ?process(Message4 * );
???? // ?overloads?of?process?for?other?messages
} ;
class ?OtherSpecificMessageHandler:
???? public ?MessageHandler
{
???? void ?process(Message1 * );
???? void ?process(Message2 * );
???? void ?process(Message3 * );
???? void ?process(Message4 * );
???? // ?overloads?of?process?for?other?messages
} ;

[列表3]

動態雙重分派

（It was against this backdrop that I developed the technique I call "Dynamic Double Dispatch."）我開發了一種技術，我稱其為“動態雙重分派”，這種技術用于解決上述問題。盡管有基本的雙重分派技術，但選擇的消息處理函數使用的是在編譯階段確定的重載技術(盡管發現在正確的消息處理器類中的實現是使用虛函數機制),而動態雙重分派是在運行時檢查在處理器上適當的處理函數的。結論是動態雙重分派消除了雙重分派的依賴問題。消息類型不在需要注意到其它的消息類型，并且處理器類僅需要注意到它的它要處理的消息。

動態檢查的關鍵點是：每一個消息類型有一個獨立的基類——處理器類從適當的，設計為處理消息的基類派生。然后在每個消息類中的分派函數能用dynamic_cast來檢查從正派基類派生的處理器類，因而實現了正確的處理函數。(列表4)

class ?MessageHandlerBase
{};
class ?Message1HandlerBase:
???? public ? virtual ?MessageHandlerBase
{
???? virtual ? void ?process(Message1 * ) = 0 ;
};
class ?Message1
{
???? void ?dispatch(MessageHandlerBase * ?handler)
????{
????????dynamic_cast < Message1HandlerBase &> ( * handler).process( this );
????}
};
class ?Message2HandlerBase:
???? public ? virtual ?MessageHandlerBase
{
???? virtual ? void ?process(Message2 * ) = 0 ;
};
class ?Message2:
???? public ?MessageBase
{
???? void ?dispatch(MessageHandlerBase * ?handler)
????{
????????dynamic_cast < Message2HandlerBase &> ( * handler).process( this );
????}
};
// ?
class ?SpecificMessageHandler:
???? public ?Message1HandlerBase,
???? public ?Message2HandlerBase
{
???? void ?process(Message1 * );
???? void ?process(Message2 * );
};
class ?OtherSpecificMessageHandler:
???? public ?Message3HandlerBase,
???? public ?Message4HandlerBase
{
???? void ?process(Message3 * );
???? void ?process(Message4 * );
};

[列表4]

(Of course, having a completely separate handler base class for each message type would add excessive complication, as the dispatch function for each message type would now be specific to that message type, and the base classes would have to be written separately, despite being fundamentally the same, except for the message type they referenced.)
誠然，為每個消息類型分別編寫的處理器基類將增加過多的復雜性，同樣地，每個消息類型各自的分派函數現在需要特別指定，基類也需求分別編寫,然后除了它們引用的消息類型外基礎是相同的。消除這種重復的關鍵是使基類成為模板，用消息類型作為模板參數——分派函數引用到模板的實現好于指定類型；請看列表5。

?

[列表5]
出于簡化原因，在消息類中的分派函數幾乎相同，但也不是完全相同——它們必須明確的指定屬于它們的指定消息類，以便于轉換為適當的處理器基類。像軟件中許多事情一樣，這個問題可以增加一個額外的層來解決——分派函數可以委托給單個模板函數，這個模板函數使用模板參數類型來確定消息類型和把處理器轉換到適當的類型上。(列表6)

?

[列表6]

通過進一步抽象在消息對象中分派函數的不同之處,我們把工作集中到一個地方——模板函數的定義；它提供了為修改行為的單一點。在消息類中剩下的分派函數都是相同的，這足以把它們簡化到隱藏細節的宏中或在消息類之間中逐字復制。

未處理的消息

迄今為止，我們展示的 dynamicDispach模板函數的代碼假定處理的類是從適當的SpecificMessageHandler是派生的；如是不是這樣， dynamic_cast將拋出std::bad_cast異常。有時這就足夠了，但是有的時候，有更適當的行為——也許更好的做法是拋棄消息，這不能被接受消息的代理處理或調用catch-all處理器。舉例來說，dynamicDispatch 函數能被調整，用基于指針的轉換代替基于引用的轉換，所以結果值可以與NULL進行測試。

缺點(Trade-Off)在哪里？
有如此多的優點，一定存在它的缺點，那它的缺點在哪里呢？在這里，有兩個缺點。第一個是：額外的動態轉換，兩個虛函數調用會影響性能。如果性能上是一個問題，這就是一個疑問，但是，在很多情況下，花銷在這里的額外的時間是不值得關注的。可以使用相應的工具來簽定到底哪里才是真正的性能瓶頸所在。

第二個缺點是:需要為每個消息處理從指定的基類派生消息處理器。因為處理新的消息類型需要修改兩個地方——適當的基類列表入口和處理函數，所以這可能成為錯誤的來源，遺失處理函數容易被發現，因為這是全局點，但是遺失基類在代碼運行時只產生不易查覺的缺陷。因為沒有處理函數的時候僅僅是不調用它。這些錯誤在單元測試的時候是很容易被抓出來的，所以所實話，這些不便之處都成不了大問題。

?