boost::function和boost:bind取代虛函數

這是一篇比較情緒化的blog，中心思想是“繼承就像一條賊船，上去就下不來了”，而借助boost::function和boost::bind，大多數情況下，你都不用上賊船。

boost::function和boost::bind已經納入了std::tr1，這或許是C++0x最值得期待的功能，它将徹底改變C++庫的設計方式，以及應用程式的編寫方式。

Scott Meyers的Effective C++ 3rd ed.第35條款提到了以boost::function和boost:bind取代虛函數的做法，這裡談談我自己使用的感受。​

以boost::function和boost:bind取代虛函數

Scott Meyers的Effective C++ 3rd ed.第35條款提到了以boost::function和boost:bind取代虛函數的做法，這裡談談我自己使用的感受。

基本用途

boost::function就像C#裡的delegate，可以指向任何函數，包括成員函數。當用bind把某個成員函數綁到某個對象上時，我們得到了一個closure（閉包）。例如：

如果沒有boost::bind，那麼boost::function就什麼都不是，而有了bind()，“同一個類的不同對象可以delegate給不同的實作，進而實作不同的行為”（myan語），簡直就無敵了。

對程式庫的影響

程式庫的設計不應該給使用者帶來不必要的限制（耦合），而繼承是僅次于最強的一種耦合（最強耦合的是友元）。如果一個程式庫限制其使用者必須從某個class派生，那麼我覺得這是一個糟糕的設計。不巧的是，目前有些程式庫就是這麼做的。

例1：線程庫

正常OO設計：

寫一個Thread base class，含有（純）虛函數 Thread#run()，然後應用程式派生一個繼承class，覆寫run()。程式裡的每一種線程對應一個Thread的派生類。例如Java的Thread可以這麼用。

缺點：如果一個class的三個method需要在三個不同的線程中執行，就得寫helper class(es)并玩一些OO把戲。

基于closure的設計：

令Thread是一個具體類，其構造函數接受Callable對象。應用程式隻需提供一個Callable對象，建立一份Thread實體，調用Thread#start()即可。Java的Thread也可以這麼用，傳入一個Runnable對象。C#的Thread隻支援這一種用法，構造函數的參數是delegate ThreadStart。boost::thread也隻支援這種用法。

使用：

例2：網絡庫

以boost::function作為橋梁，NetServer class對其使用者沒有任何類型上的限制，隻對成員函數的參數和傳回類型有限制。使用者EchoService也完全不知道NetServer的存在，隻要在main()裡把兩者裝配到一起，程式就跑起來了。

對面向對象程式設計的影響

一直以來，我對面向對象有一種厭惡感，疊床架屋，繞來繞去的，一拳拳打在棉花上，不解決實際問題。面向對象三要素是封裝、繼承和多态。我認為封裝是根本的，繼承和多态則是可有可無。用class來表示concept，這是根本的；至于繼承和多态，其耦合性太強，往往不劃算。

繼承和多态不僅規定了函數的名稱、參數、傳回類型，還規定了類的繼承關系。在現代的OO程式設計語言裡，借助反射和attribute/annotation，已經大大放寬了限制。舉例來說，JUnit 3.x 是用反射，找出派生類裡的名字元合 void test*() 的函數來執行，這裡就沒繼承什麼事，隻是對函數的名稱有部分限制（繼承是全面限制，一字不差）。至于JUnit 4.x 和 NUnit 2.x 則更進一步，以annoatation/attribute來标明test case，更沒繼承什麼事了。

我的猜測是，當初提出面向對象的時候，closure還沒有一個通用的實作，是以它沒能算作基本的抽象工具之一。現在既然closure已經這麼友善了，或許我們應該重新審視面向對象設計，至少不要那麼濫用繼承。

自從找到了boost::function+boost::bind這對神兵利器，不用再考慮類直接的繼承關系，隻需要基于對象的設計(object-based)，拳拳到肉，程式寫起來頓時順手了很多。

對面向對象設計模式的影響

既然虛函數能用closure代替，那麼很多OO設計模式，尤其是行為模式，失去了存在的必要。另外，既然沒有繼承體系，那麼建立型模式似乎也沒啥用了。

最明顯的是Strategy，不用累贅的Strategy基類和ConcreteStrategyA、ConcreteStrategyB等派生類，一個boost::function<>成員就解決問題。在《設計模式》這本書提到了23個模式，我認為iterator有用（或許再加個State），其他都在擺譜，拉虛架子，沒啥用。或許它們解決了面向對象中的常見問題，不過要是我的程式裡連面向對象（指繼承和多态）都不用，那似乎也不用叨擾面向對象設計模式了。

或許closure-based programming将作為一種新的programming paradiam而流行起來。

依賴注入與單元測試

前面的EchoService可算是依賴注入的例子，EchoService需要一個什麼東西來發送消息，它對這個“東西”的要求隻是函數原型滿足SendMessageCallback，而并不關系資料到底發到網絡上還是發到控制台。在正常使用的時候，資料應該發給網絡，而在做單元測試的時候，資料應該發給某個DataSink。

安照面向對象的思路，先寫一個AbstractDataSink interface，包含sendMessage()這個虛函數，然後派生出兩個classes：NetDataSink和MockDataSink，前面那個幹活用，後面那個單元測試用。EchoService的構造函數應該以AbstractDataSink*為參數，這樣就實作了所謂的接口與實作分離。

我認為這麼做純粹是脫了褲子放屁，直接傳入一個SendMessageCallback對象就能解決問題。在單元測試的時候，可以boost::bind()到MockServer上，或某個全局函數上，完全不用繼承和虛函數，也不會影響現有的設計。

什麼時候使用繼承？

如果是指OO中的public繼承，即為了接口與實作分離，那麼我隻會在派生類的數目和功能完全确定的情況下使用。換句話說，不為将來的擴充考慮，這時候面向對象或許是一種不錯的描述方法。一旦要考慮擴充，什麼辦法都沒用，還不如把程式寫簡單點，将來好大改或重寫。

如果是功能繼承，那麼我會考慮繼承boost::noncopyable或boost::enable_shared_from_this，下一篇blog會講到enable_shared_from_this在實作多線程安全的Signal/Slot時的妙用。

例如，IO-Multiplex在不同的作業系統下有不同的推薦實作，最通用的select()，POSIX的poll()，Linux的epoll()，FreeBSD的kqueue等等，數目固定，功能也完全确定，不用考慮擴充。那麼設計一個NetLoop base class加若幹具體classes就是不錯的解決辦法。

基于接口的設計

這個問題來自那個經典的讨論：不會飛的企鵝（Penguin）究竟應不應該繼承自鳥（Bird），如果Bird定義了virtual function fly()的話。讨論的結果是，把具體的行為提出來，作為interface，比如Flyable（能飛的），Runnable（能跑的），然後讓企鵝實作Runnable，麻雀實作Flyable和Runnable。（其實麻雀隻能雙腳跳，不能跑，這裡不作深究。）

進一步的讨論表明，interface的粒度應足夠小，或許包含一個method就夠了，那麼interface實際上退化成了給類型打的标簽(tag)。在這種情況下，完全可以使用boost::function來代替，比如：

實作Signal/Slot

boost::function + boost::bind 描述了一對一的回調，在項目中，我們借助boost::shared_ptr + boost::weak_ptr簡潔地實作了多點傳播(multi-cast)，即一對多的回調，并且考慮了對象的生命期管理與多線程安全；并且，自然地，對使用者的類型不作任何限制，篇幅略長，留作下一篇blog吧。（boost::signals也實作了Signal/Slot，但可惜不是線程安全的。）

最後，向偉大的C語言緻敬！