设计模式不能做什么
GOF指出了设计模式能够解决的问题，但是设计模式也不是万能，什么都可以做，肯定有他不能做的事情或者是用了设计模式却适得其反。
1．设计模式不是法则
模式理论的精髓之一就是模式的使用是有前提和代价的，模式是在某种前提下，综合各方面的因素考虑得出的结果。即在使用模式时总要付出一定的代价的，当然这种代价是可以接受的。如果某个模式在所有场合的使用都是必然的，那么它就不叫设计模式了，而是必须遵守的法则。例如“面向借口，而非实现编程”是法则而非模式。
模式实际上是某种语境下的解决方案。在实际的项目中，是否采用模式取决于项目是否符合模式的语境，并且是否可以接受使用模式多带来的代价。很多情况下，模式的选择不是必然的。有时可以不采用模式也可以很好地解决问题：有时可以采用一种模式代替另一种模式，或者说在特定的语境下模式的使用不是唯一的。例如命令模式将行为抽象为类，模式的实现比较简单，也容易理解。那么这个模式是否可以在所有场合使用呢？显然不可以。如果我们把所有类的方法都抽象为命令模式，这样程序是最灵活的。因为可以动态地增加行为，但代价是程序中各个类就不再具有业务含义。业务含义全部隐藏在命令对象中，这样做的结果是晦涩难懂，可维护性降低。
2．不能提高开发速度或者形象开发速度
如果一个开发周期作为考核标准，恐怕没有人会使用设计模式，设计模式并不能提高目前的开发速度，至少其关注的目标并不是开发速度，很多情况下甚至会降低开发速度，即使是使用正确的设计模式。
这是因为设计模式可能会引入更多的对象和更复杂的对象装配关系，从而使得程序有更多的动态，从局部看来变得结构复杂，难以理解并且测试困难。如果仅仅关注于形象进度，或者能够百分之百地确定需求没有变化，那么设计模式并不是很好的选择。
然而，如果从整个项目和生命周期来看，合理地使用设计模式可以使程序结构更为健壮，更具有可维护性。千万不要相信需求不会发生变化，也不要相信两周后即可完成开发。很多项目表面上早就完成，可是离开了开发人员，业务则无法进行。于是，打着维护的旗号，一直在修修补补。如果你想真正摆脱用户的纠缠，那么在设计时就不要吝啬时间和精力，健壮的结构往往会使项目能更快（从整个周期来看）完成。
3．不是万能的
设计模式的使用时自然而然的事情，很多情况下不使用设计模式是因为不需要，问题还没有复杂到非用不可的程度。我们是为了设计而使用设计模式，而不是为了使用设计模式而设计。
当你的项目发现有如下问题之一时，就需要考虑重构代码，可能会有某种模式适合。
（1）代码无法进行单元测试时；
（2）需求的变动总是导致代码的变动；
（3）由重复代码存在；
（4）继承层次过多；
（5）隐藏的以来过多；
1．设计模式不是法则
模式理论的精髓之一就是模式的使用是有前提和代价的，模式是在某种前提下，综合各方面的因素考虑得出的结果。即在使用模式时总要付出一定的代价的，当然这种代价是可以接受的。如果某个模式在所有场合的使用都是必然的，那么它就不叫设计模式了，而是必须遵守的法则。例如“面向借口，而非实现编程”是法则而非模式。
模式实际上是某种语境下的解决方案。在实际的项目中，是否采用模式取决于项目是否符合模式的语境，并且是否可以接受使用模式多带来的代价。很多情况下，模式的选择不是必然的。有时可以不采用模式也可以很好地解决问题：有时可以采用一种模式代替另一种模式，或者说在特定的语境下模式的使用不是唯一的。例如命令模式将行为抽象为类，模式的实现比较简单，也容易理解。那么这个模式是否可以在所有场合使用呢？显然不可以。如果我们把所有类的方法都抽象为命令模式，这样程序是最灵活的。因为可以动态地增加行为，但代价是程序中各个类就不再具有业务含义。业务含义全部隐藏在命令对象中，这样做的结果是晦涩难懂，可维护性降低。
2．不能提高开发速度或者形象开发速度
如果一个开发周期作为考核标准，恐怕没有人会使用设计模式，设计模式并不能提高目前的开发速度，至少其关注的目标并不是开发速度，很多情况下甚至会降低开发速度，即使是使用正确的设计模式。
这是因为设计模式可能会引入更多的对象和更复杂的对象装配关系，从而使得程序有更多的动态，从局部看来变得结构复杂，难以理解并且测试困难。如果仅仅关注于形象进度，或者能够百分之百地确定需求没有变化，那么设计模式并不是很好的选择。
然而，如果从整个项目和生命周期来看，合理地使用设计模式可以使程序结构更为健壮，更具有可维护性。千万不要相信需求不会发生变化，也不要相信两周后即可完成开发。很多项目表面上早就完成，可是离开了开发人员，业务则无法进行。于是，打着维护的旗号，一直在修修补补。如果你想真正摆脱用户的纠缠，那么在设计时就不要吝啬时间和精力，健壮的结构往往会使项目能更快（从整个周期来看）完成。
3．不是万能的
设计模式的使用时自然而然的事情，很多情况下不使用设计模式是因为不需要，问题还没有复杂到非用不可的程度。我们是为了设计而使用设计模式，而不是为了使用设计模式而设计。
当你的项目发现有如下问题之一时，就需要考虑重构代码，可能会有某种模式适合。
（1）代码无法进行单元测试时；
（2）需求的变动总是导致代码的变动；
（3）由重复代码存在；
（4）继承层次过多；
（5）隐藏的以来过多；
