CSDN博客

img zergbird

一个对c++的批评

发表于2004/6/30 21:37:00  693人阅读

继承机制
一方面是为了扩展,但是另外一方面也是限制,
父类的设计必须完美,考虑到所有子类的可能情况。
这是一个对c++的批判。

认真考虑一下这个问题,这种情况只有在类关系交错的时候才
会发生,情况的出现往往是这样吧:
class A{public fun1(){}}; //father
class B:public A{};
class C:public A{};
...              //some children

class framework
{
  USE_A(A*){..};
};

至此,A的设计完全符合framework的需要。。。

现在出现framework2,要使用class A的一个继承,class X
其中需要用到一个设计framework时候
没有遇到过的功能,也就是说,这个功能class A并不提供,
或者说没有对应的虚函数,那么现在的选择要么是
frame2work放弃对A系列类的通用性,要么放弃那个功能,
要么。。。为A增加新的虚拟函数。。。
继承机制
一方面是为了扩展,但是另外一方面也是限制,
父类的设计必须完美,考虑到所有子类的可能情况。
这是一个对c++的批判。

认真考虑一下这个问题,这种情况只有在类关系交错的时候才
会发生,情况的出现往往是这样吧:
class A{public fun1(){}}; //father
class B:public A{};
class C:public A{};
...              //some children

class framework
{
  USE_A(A*){..};
};

至此,A的设计完全符合framework的需要。。。

现在出现framework2,要使用class A的一个继承,class X
其中需要用到一个设计framework时候
没有遇到过的功能,也就是说,这个功能class A并不提供,
或者说没有对应的虚函数,那么现在的选择要么是
frame2work放弃对A系列类的通用性,要么放弃那个功能,
要么。。。为A增加新的虚拟函数。。。

这个就是被批判的父类设计需要“预测将来”的例子。。。
(我自己这么想的,可能不是)

就我个人看呢,这个问题是出在“强行把非通用的情况整合到
通用情况”,本身就是一个完美主义的自虐。。。
归根又是一个“动态类型判别问题”罢了。。。
这个问题说到底又是“层次问题”,如果用虚拟机当然
可以搞定,多增加一个层次罢了,
如果在c++上,我们同样增加一个层次比如为framework2
写出两个类,用子类去对待特殊的X,这个问题显然也可以解决。
再凶悍一点,用visitor方法把类的判别工作仍给linker也可以。

好像每次都是看“你把这个工作”放在哪个部位的问题么。。
这个就是被批判的父类设计需要“预测将来”的例子。。。
(我自己这么想的,可能不是)

就我个人看呢,这个问题是出在“强行把非通用的情况整合到
通用情况”,本身就是一个完美主义的自虐。。。
归根又是一个“动态类型判别问题”罢了。。。
这个问题说到底又是“层次问题”,如果用虚拟机当然
可以搞定,多增加一个层次罢了,
如果在c++上,我们同样增加一个层次比如为framework2
写出两个类,用子类去对待特殊的X,这个问题显然也可以解决。
再凶悍一点,用visitor方法把类的判别工作仍给linker也可以。

好像每次都是看“你把这个工作”放在哪个部位的问题么。。
0 0

相关博文

我的热门文章

img
取 消
img