设计模式不是为每个人准备的，而是基于业务来选择设计模式，需要时就能想到它 。要明白一点 ， 技术永远为业务服务 ， 技术只是满足业务需要的一个工具 。我们需要掌握每种设计模式的应用场景、特征、优缺点，以及每种设计模式的关联关系，这样就能够很好地满足日常业务的需要 。
许多设计模式的功能类似 ， 界限不是特别清楚（为了能让大家更好的理解，每个章节后面都列出了类似功能设计模式之间的对比） 。大家不要疑惑，设计模式不是为了特定场景而生的 ， 而是为了让大家可以更好和更快地开发 。
设计模式只是实现了七大设计原则的具体方式，套用太多设计模式只会陷入模式套路陷阱，最后代码写的凌乱不堪 。
在实际工作中很少会规定必须使用哪种设计模式 ， 这样只会限制别人 。不能为了使用设计模式而去做架构，而是有了做架构的需求后 ， 发现它符合某一类设计模式的结构，在将两者结合 。
设计模式要活学活用，不要生搬硬套 。想要游刃有余地使用设计模式，需要打下牢固的程序设计语言基础、夯实自己的编程思想、积累大量的时间经验、提高开发能力 。目的都是让程序低耦合，高复用，高内聚，易扩展，易维护 。
1. 需求驱动
不仅仅是功能性需求 ， 需求驱动还包括性能和运行时的需求，如软件的可维护性和可复用性等方面 。设计模式是针对软件设计的，而软件设计是针对需求的，一定不要为了使用设计模式而使用设计模式，否则可能会使设计变得复杂，使软件难以调试和维护 。
2. 分析成功的模式应用项目
对现有的应用实例进行分析是一个很好的学习途径 ， 应当注意学习已有的项目，而不仅是学习设计模式如何实现 ， 更重要的是注意在什么场合使用设计模式 。
3. 充分了解所使用的开发平台
设计模式大部分都是针对面向对象的软件设计，因此在理论上适合任何面向对象的语言，但随着技术的发展和编程环境的改善 ， 设计模式的实现方式会有很大的差别 。在一些平台下 ， 某些设计模式是自然实现的 。
不仅指编程语言，平台还包括平台引入的技术 。例如，Java EE 引入了反射机制和依赖注入，这些技术的使用使设计模式的实现方式产生了改变 。
4. 在编程中领悟模式
软件开发是一项实践工作，最直接的方法就是编程 。没有从来不下棋却熟悉定式的围棋高手，也没有不会编程就能成为架构设计师的先例 。掌握设计模式是水到渠成的事情，除了理论只是和实践积累，可能会“渐悟”或者“顿悟” 。
5.避免设计过度
设计模式解决的是设计不足的问题 ， 但同时也要避免设计过度 。一定要牢记简洁原则 ， 要知道设计模式是为了使设计简单，而不是更复杂 。如果引入设计模式使得设计变得复杂，只能说我们把简单问题复杂化了，问题本身不需要设计模式 。
这里需要把握的是需求变化的程度，一定要区分需求的稳定部分和可变部分 。一个软件必然有稳定部分，这个部分就是核心业务逻辑 。如果核心业务逻辑发生变化，软件就没有存在的必要 ， 核心业务逻辑是我们需要固化的 。对于可变的部分，需要判断可能发生变化的程度来确定设计策略和设计风险 。要知道，设计过度与设计不足同样对项目有害 。
学习设计模式，死记硬背是没用的 ， 还要从实践中理解，本教程后面会结合实例和源码来讲解如何使用设计模式 。需要特别声明的是，在日常应用中 ， 设计模式从来都不是单个设计模式独立使用的 。在实际应用中，通常多个设计模式混合使用，你中有我，我中有你 。下图完整地描述了设计模式之间的混用关系 ， 希望对大家有所帮助 。
设计模式是为了封装变化 ， 让各个模块可以独立变更，而不至于对其他模块产生非常大的影响 。使用设计模式之前，需要对现有业务需求和需求可能发生的走向，有个比较精准的预测 。然后根据现有业务以及可能发生的变化，总结出业务特点，选择合适的设计模式 。
为了避免过度设计，需要对各个设计模式进行学习和分析 。为什么会有这个设计模式？这个设计模式是为了解决什么问题？在我的业务需求中是不是有类似的问题？选择合适的才是最重要的，不能为了使用设计模式而使用设计模式 。不然以后业务需求发生变化的时候，发现设计模式不能适应业务需求的变化，只能推倒重来了，这样就失去了使用设计模式的意义 。
最后，设计模式无非就是一个工具而已，根据不同情况，选用不同的工具；如果不使用工具，能更简单方便地解决问题，那就不需要使用 。最重要的还是对业务需求有足够的认识和判断，这些都是基于你当前的领域知识和领域经验而来的 。
【程序设计模式，设计模式怎么用】
学习设计模式 ， 推荐看一下《设计模式之禅》 。
