怎样在实践中正确的应用设计模式

保持简单

  当你设计时，尽可能的用最简单的方式解决问题。你的目标应该是简单，而不是“如何在这个问题中应用模式”。千万不要认为：如果没有应用设计模式解决问题，就不是一个经验丰富的开发人员。我们只是说，为了让你的设计更加的简单和具有弹性，有时候应用设计模式是最好的方法。尽量让你的设计保持简单，这样才会让其他开发人员认可你的做法。

何时应用设计模式

  如果在你的设计中确定某个模式可以解决某个问题，那就去应用它！如果有更简单的解决方案，那么在应用设计模式之前应该优先考虑这个方案。

  如何知道何时该应用一个模式？这需要经验和知识。一旦确定一个简单的方案无法满足你的需求，应该考虑这个问题及相关约束，这可以帮助你将问题对应到一个模式。如果你对设计模式的认知比较深刻，你可能就会知道有什么模式适合这样的情况。否则，就需要调查一下可能会解决这个问题的模式。一旦找到了看起来合适的模式，首先要确定你是否能承受这个模式带来的后果，以及对设计其他部分的影响。是的，你不能将模式随便的插入、编译，然后早早的去吃午饭，使用模式，就要考虑承担模式带来的对设计其他部分的后果。如果一切都看起来没有问题，那么就毫不犹豫的使用它吧！

  有一种情况，即使有简单的解决方案，你仍然要应用设计模式。这种情况就是：你预期系统在未来会发生改变。找出系统中变化的区域，这通常是需要应用设计模式的地方。但务必要确定一件事：加入模式要应对的是可能发生的实际的改变，而不是假想的改变，否则将没有意义。

重构的时间就是应用模式的时间

  重构就是要改变既有代码的组织方式，目标是改善其结构，而不是行为。这会是一个很好的时机来检查你的设计是否是可以利用更好的设计模式来改善结构。比如假如代码中充斥了大量的条件判断，那就可能要考虑状态模式或者是工厂模式来消除依赖。

不要惧怕从系统中删除一个模式

  不要认为从系统中删除某个模式是可耻的事，也不必担心其他开发人员会嘲笑你的设计不合理，因为这是会经常发生的事，何时会删除一个模式呢？当系统变得非常复杂，并且不需要预留任何弹性的时候，不要使用模式，也就是说这时一个简单的解决方案远比应用模式更重要。

假如现在不需要，就什么也别做

  模式的威力巨大，你很容易在各种应用代码当中看到它，在各种开源框架中看到它的身影。但是要抗拒模式的诱惑，假如今天有实际的需要去支持改变，那么就放手的去应用它。如果只是假想的，就不要添加这个模式，因为这只会让你的系统越搞越复杂，而且很有可能你永远都不会用到它。

  过度的使用模式会使系统变得过度工程化，应该总是应用最简单的解决方案去完成工作，并在模式真正需要的地方才去应用它。正所谓养兵千日用兵一时，好刀用在刀刃上。

以上总结是我从《Head First设计模式》整理得来，书中讲得很不错，切入要点，这里记录一下，就当作读书笔记吧。