前言
这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
看的书是《Head First 设计模式》，记录一些书中的要点。
保持简单(Keep It Simple,/KISS)
首先，当你设计时，尽可能地用最简单的方式解决问题。你的目标应该是简单，而不是“如何在这个问题中应用模式”。千万不要认为：如果没有使用模式解决某个问题，就不是经验丰富的开发人员。如果你能够保持简单的设计，那么你将会得到其他开发人员的欣赏和尊敬。正确的说法是，为了要让你的设计简单且有弹性，有时候使用模式是最好的方法。
设计模式非万灵丹；事实上，连什么丹都算不上
如你所知道的，模式是解决一再发生的问题的通用方案。模式已经被许多开发人员实际测试过。所以，当你需要某个模式的时候，可以放心地使用它，毕竟你知道这个模式已经身经百战。
然而，模式并非万灵丹，你不能把模式插入、编译，然后就早早地去吃午餐。要使用模式，你需要考虑到模式对你的设计中其他部分所造成的后果。
你知道何时需要模式
这是最重要的问题：何时使用模式？当你在设计的时候，如果确定在你的设计中可以利用某个模式解决某个问题，那么就使用这个模式！如果有更简单的解决方案，那么在决定使用模式之前应该先考虑这个方案。
如何知道何时适用一个模式，这就需要经验和知识。一旦你确定一个简单的解决方案无法满足你的需要，应该考虑这个问题以及相关的约束这可以帮你将问题对应到一个模式中。如果你对于模式有很深的认知，就可能知道有什么模式适合这样的情况。否则，就花些时间调查一下可能会解决这个问题的模式，模式类目中的意图和应用部分会特别有用。一旦找到了一个看起来适合的模式，要先确定你是否能接受这个模式所带来的后果，以及对设计其他部分的影响。如果一切看起来都很好，就用它吧！
有一种情况，即使有更简单的解决方案，你仍然想要使用模式，这种情况就是：你预期系统在未来会发生改变。正如我们所见过的，找出你的设计中会改变的区域，通常这是需要模式的迹象。但是务必要确定一件事：加入模式是要应对可能发生的实际改变，而不是假想的改变。
并非只有在设计时才考虑引进模式，在重构(refactoring)!时也要这样做！
重构的时间就是模式的时间！
重构就是通过改变你的代码来改进它的组织方式的过程。目标是要改善其结构，而不是其行为。这是一个很好的时机，可以重新检查你的设计来看看是否能够利用模式让它拥有更好的结构。比方说，代码内如果充满了条件语句，这可能意味着需要使用状态模式，或者意味着，应该利用工厂模式将这些具体的依赖消除掉。许多书都介绍在如何利用模式进行重构，而随着技艺的增长，你需要更多地涉猎这个领域。
拿掉你所不需要的，不要害怕将一个设计模式从你的设计中删除。
那么何时应该删除个模式呢？当你的系统变得非常复杂，而且并不需要预留任何弹性的时候，就不要使用模式。换句话说，也就是当一个较简单的解决方案比使用模式更恰当的时候。
如果你现在不需要，就别做
设计模式威力很强大，你很容易就可以在当前设计中看到模式的各种应用方式。开发人员天生就热爱创建漂亮的架构以应对任何方向的改变。要抗拒这样的诱惑呀！如果你今天在设计中有实际的需要去支持改变，就放手采用模式处理这个改变吧！然而，如果说理由只是假想的，就不要添加这个模式，因为这只会将你的系统越搞越复杂，而且很可能你永远都不会需要它！
