《Head First设计模式》学习总结

写在前面：
学习过程中不仅要熟练掌握技能，理论的消化吸收也必不可少。虽然个人更倾向于学习技术类的东西（短时间的精力投入很快就能看到成效…），但看了很多前辈的经验总结后才知道理论性的东西是绝对不能忽视的，毕竟理论对实践有着重要的指导意义。而了解“设计”相关的东西，会对“实现”产生潜移默化的影响，虽然不能在短时间内看到让人欣喜的变化，但可能有一天回过头来一想“哦~，原来我这个不错的小习惯是当年在那本书上学到的啊”
一.什么是设计模式？
绕了一圈之后让我们又回到这个话题吧（看书之前问自己一遍，看完之后再问自己一遍，答案之间的差异就是感悟了）
之前：
自问：设计模式是什么？
自答：是一些系统设计的指导原则吧，不过我现在天天写代码，应该也用不到设计层面上的东西。
自问：哦，那具体是什么？
自答：不清楚，不过我见过一些前辈的代码，结构很复杂，一看就很上档次的那种，那些应该就用了设计模式吧，所以代码有没有应用设计模式应该就是高手与新手的区别了。等我成了高手之后，这种东西还不信手拈来，嗯，不说了，我写代码去了，好好积累项目经验。
…
之后：
自问：设计模式是什么？
自答：设计模式是由代码结构优化经验萃取出来的理论知识，应用成熟的设计模式能够增强代码的可复用性、可扩展性与可维护性。
自问：你好像很专业的样子，那好，既然设计模式有这么多好处，那是不是应用了设计模式的设计都是好设计？
自答：当然不是，毕竟我们不能为了使用模式而使用模式。设计模式可不能滥用，毕竟应用设计模式必须要作出一些牺牲（比如增加类结构的复杂性…），所以滥用设计模式的话是会出事的。而且，就算我们有了锤子，也不能把所有问题都看作钉子吧？
…
P.S.还记得学习正则表达式的总结：能不用就尽量不要用（最大限度的避免滥用），设计模式与之类似，不能看到什么问题都往模式上靠，只有当我们非常确定在当前情景下确实需要用设计模式来优化我们的设计时，才考虑使用设计模式（至于到底用不用，还要权衡重构的成本与优化的收益…）
二.要不要使用设计模式？
这是个值得思考的问题，毕竟现在我们已经拥有了一把锤子，要不要用它当然成了问题，毕竟不是所有的问题都可以用锤子来解决。退一步讲，即便所有问题都能用锤子解决，我们也不确定使用锤子是不是最好的解决方案（拔钉子的话，可能用钳子更好些…）
当我们拿着某个设计模式想放进我们的代码中时，最好权衡一下利弊，诚然，设计模式具有的设计上的弹性一定会给我们之后的维护变更带来些便利。但是利与弊到底哪个更多一些，我们需要先回答几个问题再做决定：
**（1）我们的项目是不是几乎不涉及维护或者没有后续版本，那么（2）我们引入设计模式还有必要吗？
（3）我们项目的规模是不是大到了不用设计模式不行的地步？
（4）这个设计模式用在这里合适吗？有没有更合适的？
（5）非要用设计模式吗？可不可以用几个简单的设计原则来代替？
引入设计模式之后，代码结构的复杂度大大增加，重构的成本我们可以接受吗？**
如果深思熟虑之后，还是觉得使用设计模式比较好，那么，放心去用吧，之后好好享受设计模式带来的好处吧
三.设计原则总结
（1）设计原则都是一些简单的指导意见，没有固定的实现，因而设（2）计原则也更加灵活，常见的设计原则如下：
（3）封装变化（把易于发生变化的部分抽出来，以减少其变化对其它部分的影响）
（4）多用组合，少用继承（组合比继承更有弹性）
（5）针对接口编程，不针对实现编程（使用接口可以避免直接依赖具体类）
（6）为交互对象之间的松耦合设计而努力（更松的耦合意味着更多的弹性）
（7）类应该对扩展开放，对修改关闭（open-close原则）
（8）依赖抽象，不要依赖具体类（减少对具体类的直接依赖）
（9）只和朋友交谈（密友原则）
（10）别找我，我会找你（Don’t call me, I will call you back.安卓开发的大原则）
（11）类应该只有一个改变的理由（单一责任原则）
能用设计原则解决的问题就不要用设计模式（杀鸡焉用宰牛刀…），因为设计原则实现起来更加灵活，更加轻巧（不用去考虑模式的条条框框…）

本文转载自http://www.w2bc.com/Article/8477，请尊重原创！