轉自：http://blog.csdn.net/Solstice/archive/2008/10/13/3066268.aspx
這是一篇比較情緒化的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（閉包）。例如：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class Foo
{
public:
void methodA();
void methodInt(int a);
};
class Bar
{
public:
void methodB();
};
boost::function<void()> f1; // 無參數，無返回值
Foo foo;
f1 = boost::bind(&Foo::methodA, &foo);
f1(); // 調用 foo.methodA();
Bar bar;
f1 = boost::bind(&Bar::methodB, &bar);
f1(); // 調用 bar.methodB();
f1 = boost::bind(&Foo::methodInt, &foo, 42);
f1(); // 調用 foo.methodInt(42);
boost::function<void(int)> f2; // int 參數，無返回值
f2 = boost::bind(&Foo::methodInt, &foo, _1);
f2(53); // 調用 foo.methodInt(53);
如果沒有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也只支持這種用法。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// 一個基於 closure 的 Thread class 基本結構
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：網絡庫
以boost::function作為橋梁，NetServer class對其使用者沒有任何類型上的限制，只對成員函數的參數和返回類型有限制。使用者EchoService也完全不知道NetServer的存在，只要在main()裡把兩者裝配到一起，程序就跑起來了。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// 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();
}
對面向對象程序設計的影響
一直以來，我對面向對象有一種厭惡感，疊床架屋，繞來繞去的，一拳拳打在棉花上，不解決實際問題。面向對象三要素是封裝、繼承和多態。我認為封裝是根本的，繼承和多態則是可有可無。用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來代替，比如：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// 企鵝能游泳，也能跑
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));
}
實現Signal/Slot
boost::function + boost::bind 描述了一對一的回調，在項目中，我們借助boost::shared_ptr + boost::weak_ptr簡潔地實現了多播(multi-cast)，即一對多的回調，並且考慮了對象的生命期管理與多線程安全；並且，自然地，對使用者的類型不作任何限制，篇幅略長，留作下一篇blog吧。（boost::signals也實現了Signal/Slot，但可惜不是線程安全的。）
