除了DAO共用还有业务逻辑共用

     今天在写代码的时候，想到这样一个问题，如果把共同的一些操作分离出来，以后需要此功能的就可以调用该功能，刚开始可能写代码比较慢（主要是设计和编码思路还没达到应该怎么设计公用功能花费更多的时间），但是随着项目的复杂度的增加，这种做法的优势就显示出来了。
      联系到dao和service之间的关系，发现了这有某种相似之处。dao层负责程序与数据库之间的基本操作（切口），service层在这种接口的调用前后增加许多业务逻辑，或者对这种接口复合操作。
      我说的还不是工具类这种这么共用的设计。工具类设计针对参数一般是基本类型，我想法还么那么宏大，对需求和操作的把握还没有如此炉火纯青的地步，所以还没能到谈工具类的层次。但是如果我们对一些东西的业务逻辑，也可以做成共用的，那么我们代码的简洁性就可以得到保证。否则，自己看到自己的代码都要好好看一下才能明白过来是什么意思。曾经看到一个帖子，说代码可以搞到一个方法两三行代码，那才是一个境界。从这个角度这样说不无道理。
      如果刚开始不能做到共有方法，可以在检视代码的时候做归纳，这样代码可能会易读一点。从零散整理为有序，代码就会易维护一点，但复杂度增加的时候，就好把握一点。
      想到这里，发现我好多代码都应该写到service里面。
      周末把代码拷回来把别人的代码也读一读，再总结总结。多分析一下，那些逻辑是可以共用的，而提供参数的高度灵活性，这些都需要很深的火候。顺着这个方向走下去，相信可以走上高效率编码之路。