随笔 - 119  文章 - 290  trackbacks - 0

博客搬家了哦,请移步
叫我abc

常用链接

留言簿(12)

随笔分类

我的博客

搜索

  •  

积分与排名

  • 积分 - 299474
  • 排名 - 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 阅读(1180) 评论(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   知识库   博问   管理