C++必知必会-第2章-多态

fiftymetre 2006-04-05 01:01:07

条款2

多态

多态（polymorphism）在一些编程教程中被弄得很神秘，而在另一些教程中则被忽略，其实它不过是C++语言所支持的一个简单而有用的概念。按照C++标准所言，“多态类型(polymorphic type)”就是带有虚函数的类类型（class type）。从设计的角度来看，“多态对象(polymorphic object)”就是一个具有不止一种类型的对象，而“多态基类(polymorphic base class)”则是一个为了满足多态对象的使用需求而设计的基类。

让我们来看一个金融期权的类型AmOption,，如图1所示。

Dea1 Priceable

/\ /\
\ /
Option
/\ /\
/ \
AmOption EurOption

图1 在一个金融期权层次结构中多态的作用。AmOption有四种类型

AmOption对象同时具有四种类型：AmOption、Option、Deal以及Priceable。由于一个类型是一组操作(参见“数据抽象[条款1]”和“能力查询[条款27]”)，因此，AmOption对象可以通过其4个接口中的任何一个进行操纵。这意味着一个AmOptionr 的实现利用或复用所有那些代码。对于AmOption这样的多态类型，从基类继承的最重要的东西就是它们的接口，而不是它们的实现。事实上，一个基类仅仅由接口组成不但常见，而且通常正是我们所希望的(参见“能力查询[条款27]”)。

当然，这里是一个需要注意的地方。如果让这种优势能够发挥出来，一个良好设计的多态类对于它的每一个基类而言必须是可替换的。换句话说，如果针对option接口编写的通用代码接受的是一个AmOption对象，那么该对象的行为最好就像一个option对象!

这并不是说AmOption对象应该和Option对象的行为完全一致（首先可能是因为Option基类的许多操作是不带任何实现的纯虚函数）。实际上，将一个多态基类（如Option）想象成一份契约更好理解一些。这个基类对其接口的用户做了某些承诺，这些承诺包括郑重的语法承诺，即特定的成员函数可以通过一些特定类型的实参进行调用，以及不太容易验证的语义上的承诺，即当一个特定的成员函数被调用时将会发生什么实际情况。像AmOption和EurOption这样的具体派生类被称为“转包者”，它们实现Option与其实户签订的契约，如图2所示。

针对Option接口编写的代码-----Option
price()
update()
/\ /\
/ \
AmOption EurOption
Price() price()

图2　一个多态的承包者及其“转包者”

举个例子，如果Option具有一个纯虚成员函数price，其作用是给出Option的当前值，那么AmOption和EurOption都必须实现这个函数。我们显然不会为这两种类型的Option实现完全一致的行为，但它们都应该计算并返回一个价格(price)，而不应该去拔打一个电话或打印一份文件。

另一方面，如果我要去访问同一个对象的两种不同接口的price函数，那么我们应该得到相同的结果。就本质而言，每一个调用都应该绑定到同一个函数：

AmOption *d = new AmOption;
Option *b = d;
d->price(); //如果一个调用的是AmOption：：price……………
b->price(); //……那么这一个也应该如此！

这是有意义的（在高级面向对象编程中，竟然有如此之多的基本常识被费解的语法所掩盖）。假如我问你“那个美国期权的当前值是什么？”，我期望得到与以下简短提问方法相同的答案：“那个期权的当前值是什么？”

当然，同样的推理也适用于对象的非虚拟函数：
b->updata() ; //如果这一个调用的是Option::updata…….
d->updata() ; //……那么这一个也是如此！

正是基类提供的契约允许针对基类接口编写的“多态”代码对特定的期权起作用，同时有助于对派生类的存在保持“健康的不知情”。换句话说，多态代码可能正在操纵AmOption和EurOption对象，但除非特别关心它们到底是什么对象，否则均被视作Option对象。各种各样“具体的”Option类型可以被添加或删除而不会影响到只关心基类Option的通用代码。比方说，如果在某一个地方出现一个AsianOption对象，那么只知道Option的多态代码也能够操作它，这全托“对其具体类型不知情”的福，如果以后这个对象消失了，也犯不着去挂念它。

出于同样的原因，像AmOption和EurOption这样具体的期权类型只需要知道基类就可以了(它们实现了基类的契约)，改变通用代码对它们也毫无影响。原则上，基类可以不知道除自身以外的任何事物。从实践的角度来看，对其接口的设计要考虑预期用户的需求，并且应该以这样的方式进行设计:派生类可以很容易地推知并实现其契约（参见“Template Method模式[条款22]”）。然而，基类应该对其派生类的具体细节全然不知，因为知道这些会不可避免地致使在类层次结构上添加或删除派生类变得困难。

和生活中一样，在面向对象设计中，“不知情”或“忽略”也是天赐之福(参见“虚构造函数与Prototype模式[条款29]”和“Factory Method模式[条款30]”)。

hi Fiftymetre，

很开心你喜欢这本书，祝阅读快乐。

Solstice说的没错，你的行为我可以理解:)

Royal

//此为荣耀的回信，我也不知道到底许不许我发呵呵，但我是这样理解的“杀之有理，但情有可原”

希望大家，把你的焦点放在学习上。

...全文