類的多態特性是支持面向對象的語言最主要的特性，有過非面向對象語言開發經歷的人，通常對這一章節的內容會覺得不習慣，因為很多人錯誤的認為，支持類的封裝的語言就是支持面向對象的，其實不然，Visual BASIC 6.0 是典型的非面向對象的開發語言，但是它的確是支持類，支持類并不能說明就是支持面向對象，能夠解決多態問題的語言，才是真正支持面向對象的開發的語言，所以務必提醒有過其它非面向對象語言基礎的讀者注意!

　　多態的這個概念稍微有點模糊，如果想在一開始就想用清晰用語言描述它，讓讀者能夠明白，似乎不太現實，所以我們先看如下代碼：

　　在c++中是允許派生類重載基類成員函數的，對于類的重載來說，明確的，不同類的對象，調用其類的成員函數的時候，系統是知道如何找到其類的同名成員，上面代碼中的a.ShowMember();，即調用的是Vehicle::ShowMember()，b.ShowMember();，即調用的是Car::ShowMemeber();。

　　但是在實際工作中，很可能會碰到對象所屬類不清的情況，下面我們來看一下派生類成員作為函數參數傳遞的例子，代碼如下：

　　例子中，對象a與b分別是基類和派生類的對象，而函數test的形參卻只是Vehicle類的引用，按照類繼承的特點，系統把Car類對象看做是一個Vehicle類對象，因為Car類的覆蓋范圍包含Vehicle類，所以test函數的定義并沒有錯誤，我們想利用test函數達到的目的是，傳遞不同類對象的引用，分別調用不同類的,重載了的,ShowMember成員函數，但是程序的運行結果卻出乎人們的意料，系統分不清楚傳遞過來的基類對象還是派生類對象，無論是基類對象還是派生類對象調用的都是基類的ShowMember成員函數。

　　為了要解決上述不能正確分辨對象類型的問題，c++提供了一種叫做多態性(polymorphism)的技術來解決問題，對于例程序1，這種能夠在編譯時就能夠確定哪個重載的成員函數被調用的情況被稱做先期聯編(early binding)，而在系統能夠在運行時，能夠根據其類型確定調用哪個重載的成員函數的能力，稱為多態性，或叫滯后聯編(late binding)，下面我們要看的例程3，就是滯后聯編，滯后聯編正是解決多態問題的方法。

　　代碼如下：

　　多態特性的工作依賴虛函數的定義，在需要解決多態問題的重載成員函數前，加上virtual關鍵字，那么該成員函數就變成了虛函數，從上例代碼運行的結果看，系統成功的分辨出了對象的真實類型，成功的調用了各自的重載成員函數。

　　多態特性讓程序員省去了細節的考慮，提高了開發效率，使代碼大大的簡化，當然虛函數的定義也是有缺陷的，因為多態特性增加了一些數據存儲和執行指令的開銷，所以能不用多態最好不用。

　　虛函數的定義要遵循以下重要規則：

　　1.如果虛函數在基類與派生類中出現，僅僅是名字相同，而形式參數不同，或者是返回類型不同，那么即使加上了virtual關鍵字，也是不會進行滯后聯編的。

　　2.只有類的成員函數才能說明為虛函數，因為虛函數僅適合用與有繼承關系的類對象，所以普通函數不能說明為虛函數。

　　3.靜態成員函數不能是虛函數,因為靜態成員函數的特點是不受限制于某個對象。

　　4.內聯(inline)函數不能是虛函數，因為內聯函數不能在運行中動態確定位置。即使虛函數在類的內部定義，但是在編譯的時候系統仍然將它看做是非內聯的。

　　5.構造函數不能是虛函數，因為構造的時候，對象還是一片未定型的空間，只有構造完成后，對象才是具體類的實例。

　　6.析構函數可以是虛函數,而且通常聲名為虛函數。

　　說明一下，雖然我們說使用虛函數會降低效率，但是在處理器速度越來越快的今天，將一個類中的所有成員函數都定義成為virtual總是有好處的，它除了會增加一些額外的開銷是沒有其它壞處的，對于保證類的封裝特性是有好處的。

　　對于上面虛函數使用的重要規則6，我們有必要用實例說明一下，為什么具備多態特性的類的析構函數，有必要聲明為virtual。

　　代碼如下：

　　從上例代碼的運行結果來看，當調用DelPN(a);后，在析構的時候，系統成功的確定了先調用Car類的析構函數，而如果將析構函數的virtual修飾去掉，再觀察結果，會發現析構的時候，始終只調用了基類的析構函數，由此我們發現，多態的特性的virtual修飾，不單單對基類和派生類的普通成員函數有必要，而且對于基類和派生類的析構函數同樣重要。