近期被外派帮助国内某公司做政府某部门OA系统。听说他们那有个成熟的java框架，使用了非常长时间，抱着学习的态度，我进入这个公司。当我熟悉了一周后，留下了非常多疑问，而这些疑问，也诱发了这次关于“抽象”这个问题的思考。大家和我一起来研究研究这些疑问。

1，概览：

        初步接触这个系统。公司的技术总监，就和我们交流了这个框架，依照总监的话就是“这个就是个简单的ssh框架，没什么！”，事实证明。尽管看似简单，可是还是有不少的点能够研究的！

        疑问：

        随着对框架的深入。我们产生了几个疑问。踢给了总监：

        （1）既然用了hibernate。为什么还大量使用了原生sql？

        （2）对基础操作的封装为什么大量使用了聚合，继承基本没实用？

        （3）前台为什么没用框架。而是一些技术的组合？

        很感谢我们的总监，无私的回答了这些问题：

        总监答案：

        （1）关于sql与hql的选择，当初他们做了不同的尝试，发现：hql尽管封装的好。可是有几个缺点：速度慢，效率低，难处理复杂表。

基于这些，他们选择了部分hql部分sql，对于这些。我们对于单表且简单的操作用hql，对于单表复杂或者多表的操作使用原生的sql，通过这样平衡面向对象和效率之间的问题！

        （2）关于继承，他们也考虑过，可是继承实现的关系太强，假设过多的使用继承就会造成类的功能过于多，而聚合是个不错的解决方式。这样再扩充或者改变的时候。就会方便一些！

        （3）前台框架他们也实用过一些，可是他们认为自己写，更有兼容性。用主要的html搭建的页面兼容性更好，而在一些诶须要特殊效果的地方。则使用一些ext的控件。这样也是个非常好的选择！

2。深入：

        随着我写了一些代码，我发现总监的想法非常丰满。可是显示非常骨感！对于我的第一个疑问，我是比較允许总监的意见的，在一些特殊须要的场合，做特殊的处理，这是种非常好的平衡。我们设计一个框架的时候。这样的平衡也是要考虑的，我们的封装绝不是隔绝最基础的实现，而是在基础的实现上。做了封装，对我们常规的操作有一个系统的抽象和封装！

        可是第二个问题，我是持久自己的一些看法的。对于继承的强关系，这的确是个问题，可是这不是阻碍我们使用的问题，在抽象这个层面，继承其技术基础一直为我们提供最优质的服务，我们回想以下向对象的三个特征：封装，继承，多态。

这三者相互作用相互碰撞才有了我们的面向对象的思维！

        我们再看看这种设计经验：多组合，少继承，低耦合。高内聚。这里我们要澄清，少继承是在一定的范围内说的。在保证内聚性方面。继承是个比較好的选择，我们看看我们的java类哪个不是继承了object这个类，这也间接的说明了问题！并且在编码中。我发现，不用继承，我会写非常多反复的代码。我就不如针对同的业务抽象不同的父类，这样，降低了至少70%的工作！

        对于第三点，我想说。前台的框架的选择是个头疼的故事，可是还是有非常多经典的额框架是我们一直用的，起码我们不就一直在用jquery吗？而今的框架已经越来越简单且强大了一味的闭门造车，我想，这个时代，已经不是那个时代了！

顺便吐槽一下，公司没有网啊，整个楼层仅仅有三台公用电脑能够上网，每天还限制为2g流量，亲，这是21世纪吗？我是不是穿越了！

3，改造：

        吐槽了这么多，事实上。我还是对这个框架比較惬意的，尽管这样和那样的问题依旧不少，可是我发现这些都不影响他的适用性，在经过我给它动了个小手术后，他的代码量已经大幅下降了，适当的使用继承这个利器，我们就是在为自己创造时间。

总结：

        观察身边的程序员们，我们是不是常常这么做，从别人那copy下他的代码。然后改几个属性，功能就万事大吉了。假设有了新任务，按我们要凭借这自己超强的记忆力，修改我们全部copy的代码。然后在从新做一边单元測试！

我们提出一个观点：一个框架搭建好之后，不论什么地方的封装，都是一个高智慧含量的复制！

        这就又牵扯一个话题了。究竟什么是复制？人copy和维护代码是一种极其昂贵的成本。而让机器自己copy维护代码是节省了千万倍成本的复制！人的作用如今来看，就在于抽象和总结了，底下的。简单的复制性活动交给机器，就像如今的3d打印一样，这是个革命，已经不是技术的革命了，而是思想的革命。智慧生物要发挥它应有的作用。copy是不须要智慧的，就交给机器吧！

这是我们这个时代的潮流。