估計(jì)標(biāo)題和摘要都說不清楚，先直接用以前的一個(gè)demo說明一下多態(tài)吧。
demo中有一個(gè)terrain類，代表地形，地形要做的工作就是調(diào)整player和enemy的高度，以便讓它們看起來是正確的站在地面上。
負(fù)責(zé)這個(gè)工作的函數(shù)是CTerrain::Support(param)，現(xiàn)在的問題是param的類型。在設(shè)定上，無論是terrain->support(player)，或者terrain->support(enemy)，Support函數(shù)內(nèi)所做的調(diào)用是完全相似的。
因此，第一直覺是，抽象出player和enemy的基類cast，并將被CTerrain::Support調(diào)用的函數(shù)寫成（純）虛函數(shù)。
代碼大概是這樣子：

接下來聊聊模板的表現(xiàn)。基于上面的代碼，把CCast類去掉，同時(shí)CPlayer和CEnemy類仍舊實(shí)現(xiàn)成員函數(shù)DoSomething1()和DoSomething2()。CTerrain類修改一下：

情況大概就是這樣子了，需要思考的是：
1，模板是編譯時(shí)刻決定選擇，多態(tài)是runtime時(shí)刻決定選擇。那么，如果事務(wù)的環(huán)境允許編譯時(shí)刻決定選擇，采用模板方案是否更有意義？CEGUI在msg－>handler的映射上采用了模板機(jī)制。
2，多態(tài)有虛擬函數(shù)表的開銷，模板的實(shí)例化，同樣有類似于函數(shù)重載的開銷。不過，多態(tài)的開銷包括時(shí)間和空間上的，而模板僅僅是空間開銷。
3，如果堅(jiān)持用模板構(gòu)建整個(gè)project，那么設(shè)計(jì)上就要抹去runtime時(shí)刻決定選擇的行為，這是否會(huì)增加程序復(fù)雜度，降低可擴(kuò)展性？