多态(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这样详细的期权范例只需要知道基类就可以了（它们实现了基类的契约），改变通用代码对它们毫无影响。原则上，基类可以不知道除自身以外的任何事物。从实践的角度看，对其接口的设计要思量预期用户的需求，而且应该以这样的方法举办设计：派生类可以很容易地推知并实现其契约。然而，基类应该对其派生类的详细细节全然不知，因为知道这些会不行制止地致使在类条理布局上添加或删除派生类变得坚苦。
