许多优秀开源项目，比如Boost，其中很多作者本身都是学者兼开发或者是带有研究性质的开发人员，在高校、非盈利组织或者商业企业的非直接盈利项目的资金支持下，在很少进度压力和商业压力的情况下，精雕细琢，多次迭代后，构建出的精品代码。用这样的标准来要求所有的软件产品，特别是商业产品（当然除去少数关系重大和长远的基础核心部分外）的构建，是不科学的，也是不合算的，因为及时占领市场和足够的盈利，以及获得用户的赞许才是商业软件最重要的目标。

回头来看金山目前开源的这些产品，比如这里讨论的金山卫士，其从推出就是免费的，是为了市场上的先期推出的同类工具软件及时比拼占领些许相关市场份额，其并不是金山的基础和核心产品；从这些先天的条件看，这个产品的商业投入不会很大同时又有快速推出的要求，能有目前这样的产品质量，是合理的，从企业角度和用户角度看也都是可以接受的。

说到这里，就感觉有必要涉及一下“重构”，这个现在大家都很重视同时也经常谈及的话题。为何大家都很重视？而且常常谈及？这其中当然有软件构建本身的特点，比如对需求理解的不断深入和调整、设计的不断改善和演进、代码风格的统一以及细节的完善等等；但是，有个大家在潜意识里都感觉到，平时却很少谈及的缘由--进度和成本，因为有了这些压力，产品的第一版往往不是很完美的，然后如果还做后续版本的话，那么就要引入重构；因为有了这些压力，在经过多年之后，如果这个产品还存在的话，那么就要进行大规模的重构。简单的说，重构之所以重要，不仅仅是软件构建本身特点所引发，也是商业压力之下的构建过程的有效应对之道。

2) 再从大多数应用中常见的类继承体系上看，
除了整个继承体系所统一开放出来的接口集（也就是由虚函数所组成），在继承体系的每个层面另外会有大量的其他辅助成员函数（其数量通常比虚函数多的多），这些成员函数完全没必要设计成虚函数；

3) 从其他语言看，
即使较新的虚拟机语言C#(Java算是较老的虚拟机语言),反而定义了比C++更为严格更为显式的成员方法实现或覆盖或重载或新建的规则；这是非常重要的对C++以及Java设计思想的反思。

4) 从语言的适用场合看，
我们现在的讨论，绝大多数情况下带有一个非常重要的默认前提，那就是在用户态模式下使用C++，如果放宽这个约束，在内核模式下使用C++，那情况又完全不同了。
引用下面这个文档的观点，http://www.microsoft.com/china/whdc/driver/kernel/KMcode.mspx
首先，用户态下非常廉价几乎不用考虑的资源，在内核中是非常昂贵的，比如内核堆栈一般就3个page；

在内核不能分页(paging)时必须保证将被执行的所有代码和数据必须有效的驻留在物理内存中，如果这时需要多驻留几张虚表以及虚表指针那还是显得非常昂贵的，同时编译器为虚函数，模板等生成代码的方式，让开发人员很难确定要执行一个函数所需要的所有代码的所在位置，因此也无法直接控制用于安置这些代码的节（个人认为可能通过progma segment/datasegment/codesegment对于代码和数据进行集中控制），因此在需要这些代码时，可能已经被page out了；

所有涉及类层次结构，模板，异常等等这样的一些语言结构在内核态中都可能是不安全的，最好是把类的使用限定为POD类，回到我们的主题虚函数，也就是说内核态下类设计中没有虚函数。