多态(Polymorphism)在一些编程教程中被弄得很神秘，而在另外一些教程中则被忽略，其实它不过是C++语言所支持的一个简单而有用的概念。按照C++标准所言，"多态类型(Polymorphic type)”就是带有虚函数的类类型。从设计的角度来看，"多态对象(Polymorphic object)"就是一个具有不止一种类型的对象，而"多态基类(Polymorphic base class)"则是一个为满足多态对象的使用需求而设计的基类。
让我们来看一个金融期权的类型AmOption，如下面的代码所示：
class Deal
{
};
class Priceable
{
};
class Option: public Deal, public Priceable
{
};
class AmOption: public Option
{
};
class EurOption: public Option
{
};
AmOption对象同时具有4个类型：AmOption, Option, Deal以及Priceable。由于一个类型是一组操作，因此，AmOption对象可以通过其4个接口中的任何一个进行操纵。这意味着从一个AmOption对象可以被针对Deal, Priceable, Option接口编写的代码所操纵，从而允许AmOption的实现利用或复用所有那些代码。对于AmOption这样的多态类型，从基类继承的最重要的东西就是它们的接口，而不是它们的实现。事实上，一个基类仅仅由接口组成不但常见，而且通常正是我们所希望的。
当然，这里有一个需要注意的地方。如果让这种优势能够发挥出来，一个良好设计的多态类对于它的每个基类而言必须是可替换的。换句话说，如果针对Option接口编写的通用代码接受的是一个AmOption对象，那么该对象的行为最好就像一个Option对象！
这并不是说AmOption对象应该和Option对象的行为完全一致(首先可能是因为Option基类的许多操作是不带任何实现的纯虚函数)。实际上，将一个多态基类(如Option)想象成一份契约更好理解一些。这个基类对其接口的用户做了某些承诺，这些承诺包括郑重的语法承诺，即特定的成员函数可以通过一些特定类型的实参进行调用，以及不太容易验证的语义上的承诺，即当一个特定的成员函数被调用时将会发生什么实际情况。像AmOption和EurOption这样的具体派生类被称为"转包类"，它们实现Option与其客户签订的契约。
举个例子，如果Option具有一个纯虚成员函数price，其作用是给出Option的当前值，那么AmOption和EurOption都必须实现这个函数。我们显然不会为这两种类型的Option实现完全一致的行为，但它们都应该计算并返回一个价格(price)，而不应该去拨打一个电话或打印一个文件。
另一方面，如果我要去访问同一个对象的两种不同接口的price函数，那么我应该得到相同的结果。就本质而言，每一个调用都应该绑定到同一个函数：
AmOption *d = new AmOption;
Option *b = d;
d->price();// 如果这一个调用的是AmOption::price()
b->price();// 那么这一个也应该如此
这是有意义的。假如我问你“那个美国期权的当前值是什么？”，我期望得到以下简短提问方式相同的答案：“那个期权的当前值是什么？”
当然，同样的推理也适用于对象的非虚函数：
b->update(); //如果这一个调用的是Option::update
d->update(); //那么这一个也是如此！
正是基类提供的契约允许针对基类接口编写的“多态”代码对特定的期权起作用，同时有助于对派生类的存在保持“健康的不知情”。换句话说，多态代码可能正在操纵AmOption和EurOption对象，但除非特别关心它们到底是什么对象，否则均被视作Option对象。各种各样“具体的”Option类型可以被添加或删除而不会影响到只关心基类Option的通用代码。比如说，如果在某一个地方出现一个AsianOption对象，那么只知道Option的多态代码也能够操作它。
出于同样的原因，像AmOption和EurOption这样具体的期权类型只需要知道基类就可以了（它们实现了基类的契约），改变通用代码对它们毫无影响。原则上，基类可以不知道除自身以外的任何事物。从实践的角度看，对其接口的设计要考虑预期用户的需求，并且应该以这样的方式进行设计：派生类可以很容易地推知并实现其契约。然而，基类应该对其派生类的具体细节全然不知，因为知道这些会不可避免地致使在类层次结构上添加或删除派生类变得困难。