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

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

Scott Meyers的Effective C++ 3rd ed.第35條款提到了以boost::function和boost:bind取代虛函數(shù)的做法，這里談?wù)勎易约菏褂玫母惺堋?/span>

原文鏈接：http://blog.csdn.net/Solstice/article/details/3066268

以boost::function和boost:bind取代虛函數(shù)

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

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

Scott Meyers的Effective C++ 3rd ed.第35條款提到了以boost::function和boost:bind取代虛函數(shù)的做法，這里談?wù)勎易约菏褂玫母惺堋?/span>

基本用途

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

class Foo {public:void methodA();void methodInt(int a); }; class Bar {public:void methodB(); }; boost::function<void()> f1; // 無參數(shù)，無返回值Foo foo; f1 = boost::bind(&Foo::methodA, &foo); f1(); // 調(diào)用 foo.methodA(); Bar bar; f1 = boost::bind(&Bar::methodB, &bar); f1(); // 調(diào)用 bar.methodB();f1 = boost::bind(&Foo::methodInt, &foo, 42); f1(); // 調(diào)用 foo.methodInt(42);boost::function<void(int)> f2; // int 參數(shù)，無返回值 f2 = boost::bind(&Foo::methodInt, &foo, _1); f2(53); // 調(diào)用 foo.methodInt(53);

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

對程序庫的影響

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

例1：線程庫

常規(guī)OO設(shè)計：

寫一個Thread base class，含有（純）虛函數(shù) Thread#run()，然后應(yīng)用程序派生一個繼承class，覆寫run()。程序里的每一種線程對應(yīng)一個Thread的派生類。例如Java的Thread可以這么用。

?

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

基于closure的設(shè)計：

令Thread是一個具體類，其構(gòu)造函數(shù)接受Callable對象。應(yīng)用程序只需提供一個Callable對象，創(chuàng)建一份Thread實(shí)體，調(diào)用Thread#start()即可。Java的Thread也可以這么用，傳入一個Runnable對象。C#的Thread只支持這一種用法，構(gòu)造函數(shù)的參數(shù)是delegate ThreadStart。boost::thread也只支持這種用法。

// 一個基于 closure 的 Thread class 基本結(jié)構(gòu) class Thread {public:typedef boost::function<void()> ThreadCallback;Thread(ThreadCallback cb) : cb_(cb){ }void start(){/* some magic to call run() in new created thread */}private:void run(){cb_();}ThreadCallback cb_;// ... };
使用：
class Foo {public:void runInThread(); };Foo foo; Thread thread(boost::bind(&Foo::runInThread, &foo)); thread.start();


例2：網(wǎng)絡(luò)庫

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

// library class Connection; class NetServer : boost::noncopyable {public:typedef boost::function<void (Connection*)> ConnectionCallback;typedef boost::function<void (Connection*, const void*, int len)> MessageCallback;NetServer(uint16_t port);~NetServer();void registerConnectionCallback(const ConnectionCallback&);void registerMessageCallback(const MessageCallback&);void sendMessage(Connection*, const void* buf, int len);private:// ... };// user class EchoService {public:typedef boost::function<void(Connection*, const void*, int)> SendMessageCallback; // 符合NetServer::sendMessage的原型EchoService(const SendMessageCallback& sendMsgCb): sendMessageCb_(sendMsgCb){ }void onMessage(Connection* conn, const void* buf, int size) // 符合NetServer::NetServer::MessageCallback的原型{printf("Received Msg from Connection %d: %.*s/n", conn->id(), size, (const char*)buf);sendMessageCb_(conn, buf, size); // echo back}void onConnection(Connection* conn) // 符合NetServer::NetServer::ConnectionCallback的原型{printf("Connection from %s:%d is %s/n", conn->ipAddr(), conn->port(), conn->connected() ? "UP" : "DOWN");}private:SendMessageCallback sendMessageCb_; };// 扮演上帝的角色，把各部件拼起來 int main() {NetServer server(7);EchoService echo(bind(&NetServer::sendMessage, &server, _1, _2, _3));server.registerMessageCallback(bind(&EchoService::onMessage, &echo, _1, _2, _3));server.registerConnectionCallback(bind(&EchoService::onConnection, &echo, _1));server.run(); }

對面向?qū)ο蟪绦蛟O(shè)計的影響

一直以來，我對面向?qū)ο笥幸环N厭惡感，疊床架屋，繞來繞去的，一拳拳打在棉花上，不解決實(shí)際問題。面向?qū)ο笕厥欠庋b、繼承和多態(tài)。我認(rèn)為封裝是根本的，繼承和多態(tài)則是可有可無。用class來表示concept，這是根本的；至于繼承和多態(tài)，其耦合性太強(qiáng)，往往不劃算。

繼承和多態(tài)不僅規(guī)定了函數(shù)的名稱、參數(shù)、返回類型，還規(guī)定了類的繼承關(guān)系。在現(xiàn)代的OO編程語言里，借助反射和attribute/annotation，已經(jīng)大大放寬了限制。舉例來說，JUnit 3.x 是用反射，找出派生類里的名字符合 void test*() 的函數(shù)來執(zhí)行，這里就沒繼承什么事，只是對函數(shù)的名稱有部分限制（繼承是全面限制，一字不差）。至于JUnit 4.x 和 NUnit 2.x 則更進(jìn)一步，以annoatation/attribute來標(biāo)明test case，更沒繼承什么事了。

我的猜測是，當(dāng)初提出面向?qū)ο蟮臅r候，closure還沒有一個通用的實(shí)現(xiàn)，所以它沒能算作基本的抽象工具之一。現(xiàn)在既然closure已經(jīng)這么方便了，或許我們應(yīng)該重新審視面向?qū)ο笤O(shè)計，至少不要那么濫用繼承。

自從找到了boost::function+boost::bind這對神兵利器，不用再考慮類直接的繼承關(guān)系，只需要基于對象的設(shè)計(object-based)，拳拳到肉，程序?qū)懫饋眍D時順手了很多。

對面向?qū)ο笤O(shè)計模式的影響

既然虛函數(shù)能用closure代替，那么很多OO設(shè)計模式，尤其是行為模式，失去了存在的必要。另外，既然沒有繼承體系，那么創(chuàng)建型模式似乎也沒啥用了。

最明顯的是Strategy，不用累贅的Strategy基類和ConcreteStrategyA、ConcreteStrategyB等派生類，一個boost::function<>成員就解決問題。在《設(shè)計模式》這本書提到了23個模式，我認(rèn)為iterator有用（或許再加個State），其他都在擺譜，拉虛架子，沒啥用。或許它們解決了面向?qū)ο笾械某Ｒ妴栴}，不過要是我的程序里連面向?qū)ο?#xff08;指繼承和多態(tài)）都不用，那似乎也不用叨擾面向?qū)ο笤O(shè)計模式了。

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

依賴注入與單元測試

前面的EchoService可算是依賴注入的例子，EchoService需要一個什么東西來發(fā)送消息，它對這個“東西”的要求只是函數(shù)原型滿足SendMessageCallback，而并不關(guān)系數(shù)據(jù)到底發(fā)到網(wǎng)絡(luò)上還是發(fā)到控制臺。在正常使用的時候，數(shù)據(jù)應(yīng)該發(fā)給網(wǎng)絡(luò)，而在做單元測試的時候，數(shù)據(jù)應(yīng)該發(fā)給某個DataSink。

安照面向?qū)ο蟮乃悸?#xff0c;先寫一個AbstractDataSink interface，包含sendMessage()這個虛函數(shù)，然后派生出兩個classes：NetDataSink和MockDataSink，前面那個干活用，后面那個單元測試用。EchoService的構(gòu)造函數(shù)應(yīng)該以AbstractDataSink*為參數(shù)，這樣就實(shí)現(xiàn)了所謂的接口與實(shí)現(xiàn)分離。

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

什么時候使用繼承？

如果是指OO中的public繼承，即為了接口與實(shí)現(xiàn)分離，那么我只會在派生類的數(shù)目和功能完全確定的情況下使用。換句話說，不為將來的擴(kuò)展考慮，這時候面向?qū)ο蠡蛟S是一種不錯的描述方法。一旦要考慮擴(kuò)展，什么辦法都沒用，還不如把程序?qū)懞唵吸c(diǎn)，將來好大改或重寫。

如果是功能繼承，那么我會考慮繼承boost::noncopyable或boost::enable_shared_from_this，下一篇blog會講到enable_shared_from_this在實(shí)現(xiàn)多線程安全的Signal/Slot時的妙用。

例如，IO-Multiplex在不同的操作系統(tǒng)下有不同的推薦實(shí)現(xiàn)，最通用的select()，POSIX的poll()，Linux的epoll()，FreeBSD的kqueue等等，數(shù)目固定，功能也完全確定，不用考慮擴(kuò)展。那么設(shè)計一個NetLoop base class加若干具體classes就是不錯的解決辦法。

基于接口的設(shè)計

這個問題來自那個經(jīng)典的討論：不會飛的企鵝（Penguin）究竟應(yīng)不應(yīng)該繼承自鳥（Bird），如果Bird定義了virtual function fly()的話。討論的結(jié)果是，把具體的行為提出來，作為interface，比如Flyable（能飛的），Runnable（能跑的），然后讓企鵝實(shí)現(xiàn)Runnable，麻雀實(shí)現(xiàn)Flyable和Runnable。（其實(shí)麻雀只能雙腳跳，不能跑，這里不作深究。）

進(jìn)一步的討論表明，interface的粒度應(yīng)足夠小，或許包含一個method就夠了，那么interface實(shí)際上退化成了給類型打的標(biāo)簽(tag)。在這種情況下，完全可以使用boost::function來代替，比如：

// 企鵝能游泳，也能跑 class Penguin {public:void run();void swim(); };// 麻雀能飛，也能跑 class Sparrow {public:void fly();void run(); };// 以 closure 作為接口 typedef boost::function<void()> FlyCallback; typedef boost::function<void()> RunCallback; typedef boost::function<void()> SwimCallback;// 一個既用到run，也用到fly的客戶class class Foo {public:Foo(FlyCallback flyCb, RunCallback runCb) : flyCb_(flyCb), runCb_(runCb){ }private:FlyCallback flyCb_;RunCallback runCb_; };// 一個既用到run，也用到swim的客戶class class Bar {public:Bar(SwimCallback swimCb, RunCallback runCb) : swimCb_(swimCb), runCb_(runCb){ }private:SwimCallback swimCb_;RunCallback runCb_; };int main() {Sparrow s;Penguin p;// 裝配起來，Foo要麻雀，Bar要企鵝。Foo foo(bind(&Sparrow::fly, &s), bind(&Sparrow::run, &s));Bar bar(bind(&Penguin::swim, &p), bind(&Penguin::run, &p)); }

實(shí)現(xiàn)Signal/Slot

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

?

最后，向偉大的C語言致敬！ 創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的boost::function和boost:bind取代虚函数的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。