框架设计或业务系统中应适当增加“上帝类”

   了解了Hibernate之后，发现Hibernate把大部分日常操作都归结为几个类.

Configuration
SessionFactory
Session
Query
Criteria

    这几个类的相互配合就能做好持久化的工作，基础编码人员页不需要了解其他的类和接口，就能很好的完成工作。这不禁让我想起我们类库中有很多工具类，业务核心类但是没有人去了解，原因是类太多了。所以在编码中经常不规范，本来基类中实现的代码到处都有重新的实现，核心的业务功能不断的被重新实现；很难管理，究其原因，是因为类太多了，设计的范围太广了。这不禁让我怀念起以前的上帝类来，当时虽然设计不优雅，但大家都知道在需要的时候调用上帝类。

    思考现在的模式，感觉目前的类库和业务核心封装应该也组织出几个数量有限的“上帝类”出来，不过此“上帝类”非彼上帝类，该“上帝类”不做功能的实现，只做Proxy或者wrap，将核心类的数量控制到最小，保证大家能尽可能的使用，真正提高代码的复用率。也许是一个好主意。