昨天把QQ拼音卸载了，换成搜狗输入法。其实平常使用的时候用哪个是无所谓的，但是在昨天那种需要频繁切换窗口，并且要频繁切换中英文状态的时候就发现了QQ拼音的不足之处（maybe it by design）。

今天稍微清闲一点，整理下资料，发现去年软件之前做的一些软考试题。整理一下共享给大家。不是很全只有04-05-06-08-09-10年的。大家有问题可以随便在我博客的哪个页面留言。一定及时回复。

在软件设计中粒度的把握就像是人际交往中热情的控制，你对人太热情了吧，别人可能觉得你有什么企图；对人太不热情了吧，别人又会觉得你这人冷血动物。这个绝对是一门学问。 既然是一门学问那就不是吾辈刹那间可以搞清楚和明白的，因此

关于Dao层的设计我现在也还是有点模糊，大大小小的项目也做了五六个了，负责的数据库设计也有三四个了。 在对Dao层进行设计时采用过两种方案：方案一：每一表对应一个Dao类（接口也可），每个Dao将

今天继续看建造者模式，打算把昨天的文章最后的那个图给实现以下，使用反射和泛型，等所有代码快写完的时候发现实现起来远不如初始的Builder代码简洁。虽然灵活性是提升了，可以产生不同的产品了，但发现目的搞错了。我是用不同的Builder来产生不同的Product，看上篇文章最后的

这样的话有什么好处呢？其实好处很多，最总要的就是这是一种“<strong>打破</strong>”，打破了原先算法骨架的死板，这里的TemplateMethod可以更加灵活，可以通过子类来实现对不同ConcreteClass的依赖，从而可以达到在客户端通过不同的AnotherClass的子类（用多态和工厂很容易实现）灵活的完成操作，而不需要知晓藏在AnotherClass后面的AbstractClass。（我怎么觉得这里有些类似于工厂方法呢。。。这个以后再谈）

在《java与模式》一书中，关于模板方法的部分最后提到了使用模板方法来重构“大方法”。我个人感觉使用模板方法在重构某一个项目时来提高类的复用是比较可行的，如果说用它来打破“大方法”我觉得就不是那么直观了。其实关键问题在于这个大方法里面是不是有重复被用到的一段代码，这样重构之后才

先从模板方法模式开始说起吧，这个模式以前看的时候没有太注意，现在又看了一遍，发现这个模式了不得呀（路人甲：其实每个模式都了不得，嘿嘿）。就是想武侠剧中的飞叶伤人，普通人眼里树叶就是树叶，而在高手眼里，那就是“草木皆兵”。同样是简单的一个继承，人家GoF就能给你整成一个模式，还是个了不得的模式。难道这就是所谓的境界吗？

设计模式是去年就专门花费大量时间学习过的内容了，见：设计模式。不过经典之所以为经典就是因为它可以经久不衰。就像是一坛陈酿，时间久了才能品出味儿来。设计模式就是一坛陈年佳酿，可谓是历久弥新。因此我们还是需要重温一下的，如果可以品到个中真味，那也可以算是收获丰盛了。

上午做了一套软考试题，就要考试了，不做题不行呀。不过做完之后郁闷的不行，虽然做的时候感觉不太好，但是对完答案也不能差这么多呀，郁闷呀，这不是打击人吗，马上就考试了。结果在总结错题的时候发现有些完全有把握的题也和答案不同，于是找同学问了一下，他刚好有这个试卷以及答案（纸质的），希赛