On The Road
(cond ((less 'code) (less 'bug)))

隨筆 - 119 文章 - 290 trackbacks - 0

博客搬家了哦，請移步
叫我abc

常用鏈接

留言簿(12)

隨筆分類

我的博客

叫我abc
博客搬家啦

搜索

積分與排名

積分 - 306721
排名 - 84

閱讀排行榜

模版與多態

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

class ??CCast

{

public :

?? virtual ?? void ??DoSomething1()? = ? 0 ;

?? virtual ?? void ??DoSomething2()? = ? 0 ;

} ;

class ??CPlayer?:? public ?CCast? {} ;

class ??CEnemy?:? public ?CCast? {} ;

class ??CTerrain

{

public :

?? void ??Support(CCast? * cast)

?? {

????cast -> DoSomething1();

????cast -> DoSomething2();

??}

} ;

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

class??CTerrain

{

public:

??template<typename?CAST>

??void??Support(CAST??*cast)

??{

????cast->DoSomething1();

????cast->DoSomething2();

??}

};

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

posted on 2006-12-20 15:37 LOGOS 閱讀(1205) 評論(3) 編輯收藏引用

FeedBack:

# re: 模版與多態 2006-12-20 20:09 pengkuny

關注回復更多評論

# re: 模版與多態 2006-12-21 14:48 Francis Arcanum

如果不考慮在運行期間動態的增加邏輯的話，模板和虛函數其實是一樣的
因為main不是模板函數，同樣C++里new T也不能變成虛函數（因為沒有反射），兩種思路歸根結底都必須在一個點上進行switch或mapping。
模板的問題在于，它缺乏一個統一的型別，因此在對模板對象進行持有的時候會有些困難。這個問題最后還是要靠虛函數來解決。回復更多評論

# re: 模版與多態 2006-12-22 15:43 小山日志

一個是運行時的動態多態；一個是編譯時的靜態多態。
一個是優先使用高內聚的類來封裝數據和算法；一個是將算法和數據分別歸類，再以接口來使用，以此提高算法和容器的利用效率（這個是STL的做法，你提出的例子好像沒有體現出來^_^）。

關于你提出的第三點，我以為那要看你的設計如何了。泛型和多態（動態的）其實目的都是提供高內聚、低耦合的設計方法，只是側重點不一樣啊回復更多評論

刷新評論列表

只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品