用 boost::function 和 boost:bind 代替虚拟函数
基本用途
boost::function就像C#里的delegate,可以指向任何函数,包括成员函数。当用bind把某个成员函数绑到某个对象上时,我们得到了一个closure(闭包)。例如:
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也只支持这种用法。
// 一个基于 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();
对面向对象程序设计的影响
一直以来,我对面向对象有一种厌恶感,叠床架屋,绕来绕去的,一拳拳打在棉花上,不解决实际问题。面向对象三要素是封装、继承和多态。我认为封装是根本的,继承和多态则是可有可无。用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而流行起来。
上一篇: C++ 虚拟函数和虚拟函数表详解
下一篇: 通过虚拟函数实现多态性的原理和分析
推荐阅读
-
用 boost::function 和 boost:bind 代替虚拟函数
-
微积分——什么是导数- 1.1 “derivative”的词源 作为名词,始于15世纪中期,词义为“a derived word or form, a word formed immediately or remotely from another or a root (派生词或派生形式,直接或者由另一个词或词根组成的词)”,由形容司“derivative (派生的)”转化而来。常用词义“that which is derived or deduced from another(由另一个事物派生或演绎而来的事物)”始于1590年代,其数学意义“a derivative function (导数函数)”始于1670年代。 1.2 “derivative”的数学意义来源 Newton(牛顿)将“derivative”称为“Fluxion(流数)”,即流(flow): f′是“流动的(fluent)”(即“流动的功变化的量”)函数f (牛顿用点号(.)代替上撇号(′)( primes);上撇号(′)( primes)是由拉格朗日(Lagrange)在18世纪末引入的)的“流数(fluxion)”。但是随着莱布尼茨的符号和他基于微分(differentials)的方法被普遍采用,牛顿的这个方便的术语就被废弃了。 函数导数的传统名称曾经称为“微分系数(Differential Coefficient)”。之所以使用这个名称是因为当我们将等式写作df(x)=f′(x)dx时f′(x)是dx(微分)的系数。事实上,在18世比和19世纪早期,数学家们对无穷小微分比微分系数更感兴趣。 然而,随着分析变得越来越严谨,注意力转向了导数f′而不是微分f′(x)dx。认识到,函数导数f′是由函数“导出的、衍生出的、演绎出的、推导出的、等等(derived)”,在语法意义上,名词的复数形式是派生于名词的单数形式。在拉丁语中,动词“dērīvāre”词义为“to lead or draw off (water or liquid), to divert, derive (words)(引导或脱去(水或液体),转移、派生(词汇))”,可以解析为由前缀“dē”(词义为“from(来自)”)+“rīvus”(词义为“*, stream of water(小溪、水流)”)构成。这就是对于函数导数f′“导数函数(derived function)”或者“导数(derivative)”的源头。 尽管“derive”流行用于表示导数计算的动词,大部分数学家喜欢用“微分(differentiate)”表示,例如: “针对x微分, 你将会得到相同的函数。” 1.3 “derivative”中文翻译为“导数” 根据前面的叙述,函数导数f′是由函数“导出的、衍生出的、演绎出的、推导出的、等等(derived)”的意义,中文将其翻译为“导数”。 2. “导数(derivative)”的数学意义
-
C++闭包与Boost::bind:函数对象和仿函数的运用