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

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

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