一个对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也可以。 好像每次都是看“你把这个工作”放在哪个部位的问题么。。