一个对c＋＋的批评

继承机制
一方面是为了扩展，但是另外一方面也是限制，
父类的设计必须完美，考虑到所有子类的可能情况。
这是一个对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也可以。

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