浅谈多态

　　多态性，这个面向对象编程领域的核心概念，本身的内容博大精深，要以一文说清楚实在是不太可能。加之作者本人也还在不断学习中，水平有限。因此本文只能描一下多态的轮廓，使读者能够了解个大概。如果有描的不准的地方，欢迎指出，或与作者探讨（作者Emailnicrosoft@sunistudio.com）

　　首先，什么是多态（Polymorphisn）？按字面的意思就是“多种形状”。我手头的书上没有找到一个多态的理论性的概念的描述。暂且引用一下Charlie Calverts的对多态的描述吧——多态性是允许你将父对象设置成为和一个或更多的他的子对象相等的技术，赋值之后，父对象就可以根据当前赋值给它的子对象的特性以不同的方式运作（摘自“Delphi4 编程技术内幕”）。简单的说，就是一句话：允许将子类类 型的指针赋值给父类类型的指针。多态性在Object Pascal和C++中都是通过虚函数（Virtual Function）实现的。 

　　好，接着是“虚函数”（或者是“虚方法”）。虚函数就是允许被其子类重新定义的成员函数。而子类重新定义父类虚函数的做法，称为“覆盖”（override），或者称为“重写”。

　　这里有一个初学者经常混淆的概念。覆盖（override）和重载（overload）。上面说了，覆盖是指子类重新定义父类的虚函数的做法。而重载，是指允许存在多个同名函数，而这些函数的参数表不同（或许参数个数不同，或许参数类型不同，或许两者都不同）。其实，重载的概念并不属于“面向对象编程”， 重载的实现是：编译器根据函数不同的参数表，对同名函数的名称做修饰，然后这些同名函数就成了不同的函数（至少对于编译器来说是这样的）。如，有两个同名函数：function func(p:integer):integer; 和function func(p:string):integer;。那么编译器做过修饰后的函数名称可能是这样的：int_func、str_func。对于这两个函数的调用，在编译器间就已经确定了，是静态的（记住：是静态）。也就是说，它们的地址在编译期就绑定了（早绑定），因此，重载和多态无关！真正和多态相关的是“覆盖”。当子类重新定义了父类的虚函数后，父类指针根据赋给它的不同的子类指针，动态（记住：是动态！）的调用属于子类的该函数，这样的函数调用在编译期间是无法确定的（调用的子类的虚函数的地址无法给出）。因此，这样的函数地址是在运行期绑定的（晚邦定）。结论就是：重载只是一种语言特性，与多态无关，与面向对象也无关！

　　引用一句Bruce Eckel的话：“不要犯傻，如果它不是晚邦定，它就不是多态。”

　　那么，多态的作用是什么呢？我们知道，封装可以隐藏实现细节，使得代码模块化；继承可以扩展已存在的代码模块（类）；它们的目的都是为了——代码重用。而多态则是为了实现另一个目的——接口重用！而且现实往往是，要有效重用代码很难，而真正最具有价值的重用是接口重用，因为“接口是公司最有价值的资源。设计接口比用一堆类来实现这个接口更费时间。而且接口需要耗费更昂贵的人力的时间。” 

　　其实，继承的为重用代码而存在的理由已经越来越薄弱，因为“组合”可以很好的取代继承的扩展现 有代码的功能，而且“组合”的表现更好（至少可以防止“类爆炸”）。因此笔者个人认为，继承的存在很大程度上是作为“多态”的基础而非扩展现有代码的方式了。

　　什么是接口重用？我们举一个简单的例子，假设我们有一个描述飞机的基类（Object Pascal语言描述，下同）：

　　type
　　　　plane = class
　　　　public
　　　　　　procedure fly(); virtual; abstract; //起飞纯虚函数
　　　　　　procedure land(); virtual; abstract; //着陆纯虚函数
　　　　　　function modal() : string; virtual; abstract; 
　　　　　　//查寻型号纯虚函数
　　　　end;

　　然后，我们从plane派生出两个子类，直升机（copter）和喷气式飞机（jet）：

　　　　copter = class(plane)
　　　　private
　　　　　　fModal : String;
　　　　public
　　　　　　constructor Create();
　　　　　　destructor Destroy(); override;
　　　　　　procedure fly(); override;
　　　　　　procedure land(); override;
　　　　　　function modal() : string; override;
　　　　end;

　 　　 jet = class(plane)
　　　　private
　　　　　　fModal : String;
　　　　public
　　　　　　constructor Create();
　　　　　　destructor Destroy(); override;
　　　　　　procedure fly(); override;
　　　　　　procedure land(); override;
　　　　　　function modal() : string; override;
　　　　end;

　　现在，我们要完成一个飞机控制系统，有一个全局的函数 plane_fly，它负责让传递给它的飞机起飞，那么，只需要这样：

　　procedure plane_fly(const pplane : plane);
　　begin
　　　　pplane.fly();
　　end;

　　就可以让所有传给它的飞机（plane的子类对象）正常起飞！不管是直升机还是喷气机，甚至是现在还不存在的，以后会增加的飞碟。因为，每个子类都已经定义了自己的起飞方式。

　　可以看到 plane_fly函数接受参数的是 plane类对象引用，而实际传递给它的都是 plane的子类对象，现在回想一下开头所描述的“多态”：多态性是允许你将父对象设置成为和一个或更多的他的子对象相等的技术，赋值之后，父对象就可以根据当前赋值给它的子对象的特性以不同的方式运作。

　　很显然，parent = child; 就是多态的实质！因为直升机“是一种”飞机，喷气机也“是一种”飞机，因此，所有对飞机的操作，都可以对它们操作，此时，飞机类就作为一种接口。

　　多态的本质就是将子类类型的指针赋值给父类类型的指针（在OP中是引用），只要这样的赋值发生了，多态也就产生了，因为实行了“向上映射”。

　　应用多态的例子非常普遍，在Delphi的VCL类库中，最典型的就是：TObject类有一个虚拟的Destroy 虚构函数和一个非虚拟的Free函数。Free函数中是调用Destroy的。因此，当我们对任何对象（都是 TObject的子类对象）调用 .Free();之后，都会执行 TObject.Free();，它会调用我们所使用的对象的析构函数 Destroy();。这就保证了任何类型的对象都可以正确地被析构。

　　多态性作为面向对象最重要的特性，本文所提不过是沧海一粟，还有很多内容。如果可能，希望会有后文继续探讨多态。

再谈多态——向上映射及VMT／DMT

　　在《浅谈多态——概念描述》一文中，提到多态的本质就是“将子类类型的指针赋值给父类类型的指针”。那么，为什么这种赋值是允许的，或者说是安全的呢？反过来行不行？虚函数的动态绑定是如何实现的呢？这些问题都将在本文得到解答。

　　假设有如下代码（Object Pascal语言描述）：
　　T1 = class
　　private
　　　　member1 : integer;
　　public
　　　　function func1 : Integer; virtual;
　　　　function func2 : Integer; virtual;
　　　　function func3 : Integer; virtual;
　　end;

　　T2 = class(T1)
　　private
　　　　member2 : integer;
　　public
　　　　function func1 : Integer; override;
　　　　function func2 : Integer; override; 
　　end;
　　最终结果是，T1类的实例的内存分布图如下（仅说明原理，并不表示编译器一定也是如此实现）：
　　___________________　　　　 _______________ 
　　|   vptr      ____________|------->    | T1.func1_____      |
　　| member1_________   |______  |  T1.func2_____     |
　　~~~~~~~~~~~~~~~~~~~_______| T1.func3_____      | 
　　　　　　　　　　　　　　　　          ~~~~~~~~~~~~~~~~ 
　　其中，vptr是编译器自动加入的一个成员指针（称为虚指针）。只有存在虚函数或动态函数或纯虚函数的类才会被编译器加入这个成员指针，该指针指向一个称为“虚函数表”（Object Pascal中成为“虚方法表”——VMT）的内存区域。虚函数表中，保存了每一个虚函数的入口地址。 
　　T2类的实例的内存分布图如下：
　　___________________　　　　 ________________
　　| vptr____________        |------->    | T2.func1______       |
　　| member1_________   |______  | T2.func2______       |
　　| member2_________   |______  | T1.func3______       |
　　~~~~~~~~~~~~~~~~~~~　　　　 ~~~~~~~~~~~~~~~~ 
　　从图中我们可以知道，子类对象所占的空间大于父类对象所占空间。因此，当发生将子类类型的指针赋值给父类类型的指针的赋值时（即所谓的“向上映射”），也就是父类类型的指针指向了子类类型的对象所占的内存空间，那么，很显然，可以保证父类类型指针的可访问范围都是有效，所以这种“向上映射”是绝对安全的（所谓“向上”是指类层次的上下关系，父类在上，子类在下）。这种赋值是得到编译器认可的。
　　也可以很容易得出结论，“向下映射”则未必安全（除非程序员真正知道指针所指对象的实际类型）。因此，这种赋值是不被编译器允许的，当然，程序员可以通过类似 T1(Obj) 的形式进行强制类型转换，但这种强制类型转换很不安全（可以发生在任何类和类之间），Object Pascal推荐使用 as 算符进行类型之间的转换，如： (Obj as T1)，使用 as 算符，编译器会检查对象类型和目标类型是否相容。如果相容，转换被允许，否则编译出错。

　　接着，我们看看虚函数的动态绑定是如何实现的。先看如下代码：
　　procedure Test;
　　var O : T1;
　　begin
　　　　O := T2.Create; 
　　　　O.func1; 
　　　　O.func3; 
　　　　O.Free;
　　end;
　　看着上面的内存布局图，当执行 O := T2.Create; 后，一个 T1 类型的指针指向 T2 实体。执行 O.func1 时，编译器通过 vptr 找到虚函数表，在虚函数表中定位到了 T2.func1（由于 T1.func1 被“覆盖”了，因此虚函数表中找不到 T1.func1），于是，T2.func1 被调用，这就是动态绑定！但由于 T2 没有重写 func3，因此 O.func3 将调用 T1.func3，这一点在虚函数表中也可以很明显看出来。

　　好了，说到这里，我想动态绑定已经说的非常清楚了，说明一点，本文虽然以 Object Pascal代码为例，但其原理对于 C++也同样有效。C++与Object Pascal（甚至不同C++编译器之间）的区别仅在于类成员及vptr在内存中分布的位置而已。

　　那么，最后再谈一下 Object Pascal 独有的 DMT（动态方法表）吧。在VMT中，我们看到，子类的虚函数表完全继承了父类的虚函数表，只是将被覆盖了的虚函数的地址改变了。每个子类都有一份自己的虚函数表，可以想象，随着类层次的扩展，如果类层次非常深，或者子类的数量非常多的话，虚函数表将称为占用内存量非常大的东西（即所谓的“类爆炸”）。为了防止这种情况， Object Pascal 引入了 DMT。对于程序员来说，区别仅在于使用“dynamic”关键字代替“virtual”关键字，所实现的功能也完全一样。 如果把本文开头的那段代码重写如下（用 dynamic 代替 virtual）：
　　T1 = class
　　private
　　　　member1 : integer; 
　　public 
　　　　function func1 : Integer; dynamic; 
　　　　function func2 : Integer; dynamic; 
　　　　function func3 : Integer; dynamic; 
　　end;
　　T2 = class(T1)
　　private
　　　　member2 : integer; 
　　public
　　　　function func1 : Integer; override; 
　　　　function func2 : Integer; override;
　　end;
　　那么，T1 的内存分布图没有改变，而 T2 实例的就不一样了：
　　___________________　　　 　_____________
　　| dptr____________        |------->    | T2.func1_____|
　　| member1_________    |_______| T2.func2_____|
　　| member2_________    |________~~~~~~~~~~~
　　~~~~~~~~~~~~~~~~~~~
　　可以看到，在 T2 的动态方法表中，没有被覆盖的 T1.func3 消失了。因此：
　　procedure Test; 
　　var O : T1; 
　　begin 
　　　　O := T2.Create; 
　　　　O.func3; 
　　　　O.Free;
　　end;
　　O.func3 这一句代码将被编译器做更多的处理：找到 T1 类的 func3 函数的入口地址，然后再调用。

　　比较一下 VMT 和 DMT 的区别： VMT 中的虚函数非常齐全，因此对每个虚函数的入口地址只需要简单的 [vptr + n] 的运算即可得到，但是 VMT 容易消耗内存（有冗余）。而 DMT 比较节省空间，但要定位到没有被覆盖的函数的入口地址时，将非常耗费时间。 一般情况下，几乎每个子类都要覆盖的函数／方法，就将它声明为 virtual；如果类层次很深，或子类很多，但某个函数／方法只被很少的子类覆盖，就将它声明为 dynamic。当然，具体就需要自己把握来选择了。

三谈多态——善用virtual

　　多态性，是一种能给程序带来灵活性的东西。看过《设计模式》的程序员应该都知道，相当多的模式（几乎所有）都是依靠多态来实现的，以此给程序提供可扩展、可重用性。在《再谈多态——向上映射及VMT／DMT》一文中，提到了多态性是依赖于虚函数／虚方法（即动态绑定）来实现的，也介绍了虚函数／虚方法（virtual）的实现方法。那么本文就来谈一下，如何使用virtual、善用virtual来获取多态性给我们带来的灵活性。

　　实例是最好的教材，因此本文还是假设一个需求，写一个实例来讲解。不过，我想没有必要给出所有源码，因此在本文中有些实现的代码会粗略带过。另外，本文所有代码均为Object Pascal语言编写，实现环境为Delphi。

　　另外，由于“方法（Method）”一词已经成为Object Pascal的术语，因此，以下称成员函数都为“方法”。也许C++程序员会不太适应这样的称呼（呵呵，我自己也不太适应），见谅吧。

　　假设我们要编写一个纯文本内的编辑器，也就是记事本（呵呵，别嫌例子老套，记事本程序在相当多方面都是很好的教材），编辑控件我们一般会用TMemo或TRichEdit，但是它们的功能都不甚强大，也许我们目前没有，但日后会找到一个更好的第三方文本编辑控件（比如，支持语法着色的）。因此，我们必须为未来的改进留下方便之门，否则到时候再重写全部程序真是太傻了。

　　界面层（菜单响应、状态显示等）对文本编辑器控件的控制的代码对于所有编辑器来说都是类似的，应该可以被重用。那么就必须将界面层的代码与编辑器控件的控制代码隔离开来。

　　如何隔离？我们可以为所有的编辑器控件指定一个公共的接口（抽象类），界面层只看得到这个接口，只使用接口提供的功能，那么，我们更换任何编辑器控件时，都不必更改界面层的代码了。

　　首先，抽象出编辑器的基本操作，如：Load（打开文本）、Save（保存到文件）、Copy（复制到剪贴板）等等，将这些操作作为public方法。其次，考虑这些操作中有哪些会涉及到具体相关控件的，对于这些操作，你有两种选择：1、如果完全依赖控件本身的，可以选择将其定义为虚方法或抽象虚方法（即C++中的纯虚函数）；2、如果只是有部分代码依赖控件本身的，将这部分操作抽象到一个protected的抽象虚方法中，而将相同的部分代码写在基类中，并由基类的方法中调用protected的抽象虚方法。

　　如果还没有完全明白，请看代码：

　　TEditor = class // 抽象基类
　　private
　　　　m_FileName : String;
　　protected
　　　　function DoLoad(FileName : String) : Boolean; virtual; abstract;
　　public 
　　　　function Load(FileName : String) : Boolean; 
　　　　function Save() : Boolean; 
　　　　function SaveAs(FileName : String) : Boolean; virtual; abstract;
　　　　// ... 其他需要的操作，由需求而定 
　　end;

　　好，我们来详细说明一下TEditor为什么是这个样子的。其有一个私有成员，保存编辑器所对应的文件名。然后看public部分，它至少提供了三个操作：Load——从某文件中读取文本到编辑器；Save——将文本保存到文件，文件名为m_FileName所保存的；SaveAs——以指定的一个文件名保存文本。

　　三个操作中，SaveAs为抽象虚方法，因为它的实际动作与每个编辑控件相关，而基类本身并不知道该如何保存文件。

　　Save和Load都是非虚方法，其中Save的任务很简单，就是将文本以m_FileName所保存的文件名保存，其实现可以是调用抽象的SaveAs，只需要将文件名传给SaveAs即可。基类完全可以确定如何完成Save（因为它可以保证派生类实现了SaveAs），因此其为非虚方法。

　　而Load呢？Load操作的步骤是：1、将文本从文件中读取到编辑器控件中；2、将m_FileName的值设置为所读取的文件名。其中第一个步骤与具体编辑器控件相关，应该是由派生类去实现它，第二个步骤派生类无法实现，因为派生类看不到私有的m_FileName成员。但即使把m_FileName移到protected节中，以使派生类可以访问它，也并非好办法，因为这样的话，在实现每个派生类时，都要记住设置m_FileName的值，这不仅造成代码重复（每个派生类都要这样做），而且这不应该是派生类的义务。因为m_FileName应该是基类的内部实现，对外不可见。因此，第二个步骤应该由基类来完成。如何达成这个目的呢？

　　我们可以注意到，protected节中有一个DoLoad方法，它就被用来完成第一个步骤——每个编辑器控件去将文本读入编辑器。然后，DoLoad由Load方法中被选择在适当的时机调用。

　　基类的实现如下：

　　function TEditor.Load(FileName : String) : Boolean;
　　begin
　　　　Result := DoLoad(FileName);
　　　　if Result then
　　　　　　m_FileName := FileName;
　　end;

　　function TEditor.Save() : Boolean;
　　begin
　　　　SaveAs(m_FileName); // 调用抽象的 SaveAs 
　　end;

　　接着，我们使用TMemo来实现一个编辑器类：

　　TMemoEditor = class(TEditor)
　　private
　　　　m_Editor : TMemo;
　　protected
　　　　function DoLoad(FileName : String) : Boolean; override; 
　　public
　　　　constructor Create();
　　　　destrcutor Destroy(); override;

　　　　function SaveAs(FileName : String) : Boolean; override;
　　　　// ...其它需要的操作
　　end; 

　　在该派生类中，有一个私有成员，即TMemo控件的实例。然后覆盖（override）了基类的两个抽象虚方法：DoLoad和Save。

　　其实现如下：

　　function TMemoEditor.Create();
　　begin
　　　　// 创建TMemo实例 
　　　　m_Editor := TMemo.Create(nil);

　　　　// 接着完成将TMemo实例置于界面上显示出来等操作，省略 
　　end;

　　function TMemoEditor.Destroy();
　　begin
　　　　// 其他清理工作
　　　　m_Editor.Free();
　　　　m_Editor := nil;
　　end;

　　function TMemoEditor.DoLoad(FileName : String) : Boolean;
　　begin 
　　　　Result := false; 
　　　　try
　　　　　　m_Editor.LoadFromFile(FileName);
　　　　except end;
　　　　Result := true;
　　end;

　　function TMemoEditor.SaveAs(FileName : String) : Boolean;
　　begin
　　　　Result := false;
　　　　try
　　　　　　m_Editor.SaveToFile(FileName);
　　　　except end;
　　　　Result := true; 
　　end;

　　很好，这样的实现已经可以使个部分运作正常了。如果，今后找到更好的编辑器控件，只需要从TEditor派生，再实现一个TXXXEditor类即可，其他部分的代码不用作任何改动。而且，具体实现的TXXXEditor类中的代码，只和具体控件本身特性相关（如：读取、保存文件的方法），而公共逻辑也已经在TEditor类中实现了。

　　virtual的使用方法，基于笔者个人认识与经验：

　　1、如果基类不知道如何实现某方法（只有派生类知道），而基类的其他方法又必须使用该方法，则把该方法声明为抽象虚方法—— virtual; abstract;（即C++的纯虚函数）。

　　2、如果基类能够为某方法提供一种默认实现，但派生类可能完全重写这个实现，则将该方法声明为虚方法—— virtual;并实现默认算法。

　　3、如果基类能够且必须提供某方法的部分的实现，而派生类必须提供另一部份的实现，则将该方法声明为非虚方法，并在基类中为其配套提供一个虚方法或抽象虚方法，以允许由基类本身调用和被派生类覆盖。犹如上例中的Load与DoLoad。

　　善用virtual，善用多态，你的代码将更具灵活性！ 

原文出处：东日软件开发者网络（SSDN）http://www.sunistudio.com/ssdn/
nicrosoft@sunistudio.com