【Boost】以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就像C#里的delegate，可以指向任何函數，包括成員函數。當用bind把某個成員函數綁到某個對象上時，我們得到了一個closure（閉包）。例如：
[cpp]?view plaincopy
如果沒有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也只支持這種用法。
[cpp]?view plaincopy
例2：網絡庫
以boost::function作為橋梁，NetServer class對其使用者沒有任何類型上的限制，只對成員函數的參數和返回類型有限制。使用者EchoService也完全不知道NetServer的存在，只要在main()里把兩者裝配到一起，程序就跑起來了。
[cpp]?view plaincopy
對面向對象程序設計的影響
一直以來，我對面向對象有一種厭惡感，疊床架屋，繞來繞去的，一拳拳打在棉花上，不解決實際問題。面向對象三要素是封裝、繼承和多態。我認為封裝是根本的，繼承和多態則是可有可無。用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來代替，比如：
[cpp]?view plaincopy
實現Signal/Slot
boost::function + boost::bind 描述了一對一的回調，在項目中，我們借助boost::shared_ptr + boost::weak_ptr簡潔地實現了多播(multi-cast)，即一對多的回調，并且考慮了對象的生命期管理與多線程安全；并且，自然地，對使用者的類型不作任何限制，篇幅略長，留作下一篇blog吧。（boost::signals也實現了Signal/Slot，但可惜不是線程安全的。）
?
最后，向偉大的C語言致敬！
總結
以上是生活随笔為你收集整理的【Boost】以boost::function和boost:bind取代虚函数的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【Boost】boost库中bind的用
- 下一篇： 【Boost】boost库中functi