这段时间接了别人的一个小项目，这个项目不大，需求文档也就10几页，而且里面主要是流程图，具体业务逻辑非常少。一个大的方法几乎可以涵盖所有的东西，但这哥们就是要套用设计模式，一上来就是命令模式，说是命令模式，其实就是命名叫command，在这个所谓的“Command”模式里面掺杂了proxy模式，filter模式，还有什么工厂模式。真叫一个“坑爹”啊。本来就是2－3个类能解决的问题，一下子就出来二三十个，依赖关系还比较乱。能有关系的地方都用上了模式。
写这个文章的主要目的是想分享一下自己的一些看法，上面这小段算是个引子。
在刚学设计模式的时候，也喜欢到处宣扬设计模式的优点，并喜欢在代码里面套用，当初就特别注意《Design Patterns》里面在每个模式开始的地方写的一些前置条件。也就是关于应用场景的说明。于是出现了一种情况：手里拿着锤子，发现什么都像钉子。明明不符合场景的地方，顿时觉得就特别适合这种设计模式，到最后把自己也搅和在一片混乱依赖之中。自己有过这样的痛苦经历，再次碰到印象特别深刻。所以现在就特别特别想就设计模式这个“好东西”再剖析一番。
我们经常听说“xx是把双刃剑”，设计模式也符合这种情况，尤其是在我们想应用的“时候”，而这个“时候”尤其不能是在设计的建立第一印象的时候。在这篇文章里面，我提起过，要是《重构》能再扩展一些，将重构的方法跟设计模式结合起来，会更加有价值。为什么这样说呢？因为，一是我们要重构，是因为现在的代码不利于扩展，或不便于维护，还有一点就在于我们如何验证重构的准确性。按照《重构》的方法论进行操作之后，我们的代码真的架构结构上就变得很严谨了么？还是在那篇文章里面我提到过，我们可能会抽取出很多的类，对象，方法等等元素，但是如何合理的对他们进行组合？仅仅是换个包依赖或者调用就可以么？实际上，在《重构》里面也是多次提起，英国根据业务需要进行划分，那这个时候就应该考虑一下设计模式。设计模式的出发点就是扩展性，稳定性和松耦合，这正是我们重构要达到的目的，当然这个时候我们依然要提醒自己，不要客气套用设计模式。与此同时，我们还要联想一下《design patterns》里面按照创建性，结构性，行为三个方面归类了设计模式，那么在进行重构的时候，我们可以结合那三个方面考虑是否有模式适用当前场景。
经过《重构》的代码，首先是基于一种场景的，而重构中每一步操作还需要准备单元测试，结合TDD，我们可以很快的验证我们的设计是否正常，是否违背我们的易于维护，易于扩展，高內聚，低耦合的目的。
因为还要写spring框架的分析， 这个帖子想专注与设计模式方面，能再好好总结总结，未完待续。