不论是编码还是架构设计都逃不过设计模式， 因为合理使用一些设计模式可以怎么我们地图的扩展性，可维护性等，另外也简化了设计实现难度，有大量文章或代码可参考。然而很多开发发费了很多时间与经历去学习记忆GoF 23种设计模式， 但很少人在自己的实际项目中去应用这些设计模式，推脱的理由能找到很多，但大部分根本理由多设计模式只是学而没真正理解。 这部分人在学习设计模式的目的是不正确的， 常见有以下几种：

考试或面试需要。 很多技术考试或面试会问到，需要应付考试或面试。增加知识面。 设计模式当知识点学习。跟风或被迫学习。 很多公司技术组有专题学习。

因为学习目的本就不是用的， 自然在实际编码过程中要嘛“忘了” 可以用，或“没想到” 能用，相信这种情况很多技术Leader在代码review是司空见惯的。 另外因为学习的目的与设计模式提出的目的不一致， 学习过程也是很痛苦的，需要记忆那么多类结构图。那么我们应该带什么样目的去学习设计模式呢？根据上文也可以猜出，个人认为最好目的是“用”，而要用好的前提是理解，知道什么时候适合用，什么时候不适合， 适合的是哪种或哪几种模式， 是否改变形或是否多模式组合使用等等。哪我们怎么去理解呢？ 我觉得有两个方面： 什么是设计模式和设计模式起作用的原理是什么。

什么是设计模式？

都知道设计模式并不是软件开发工程专有的，各行特别是工程领域都有自己的设计模式。具体软件工程领域什么时候应用设计模式，不可知，但20世纪70年代GoF受建筑领域设计模式影响, 通过总结之前软件里的经验，写的一本著名的参考书《设计模式：可复用面向对象软件的基础》，极大的推动了设计模式被大家熟知并应用。GoF将设计模式定义为： 对被用来在特定场景下解决一般设计问题的类和相互对象的描述。我们可以适当泛化，理解为对某一类问题的通用解决方案。 明显，设计模式是来源于实践经验，是对之前最佳实践的提炼总结，是用来解决实际中特定问题的方案，而不是非常抽象的概念，是不能死记硬背，也不需要实际硬背的。如学习GoF 23种设计模式，我们应该深入理解各模式解决能解决问题是什么，了解使用该方案的好处是什么，而不是背诵概念与类图。

设计模式起作用的原理是什么?

我们在实际开发中经常遇到某些问题可以用设计模型，但是有好几种模式都可以，该如何选择；或者看着能用某种设计模式，但用了后又不能完全解决问题。这时候需要我们队设计模式原理有充分的了解，知道模式起作用的原理及代理优点和缺点，能通过灵活组合或变形模式来解决现有问题。 比如简单工厂模式，就是通过将对象创建与核心业务分离方式，降低核心业务的耦合度，是核心业务满足开闭原则，具有更好的扩展性并且实现简单，易理解等都是其优势。但也要认识到对整个系统来说其并未完全解决开闭问题， 扩展仍涉及到原有代码的修改。 如果系统对扩展有更高要求，比如需要指出第三方扩展，则应当适当扩展， 比如引入SPI。 其实，仔细分析下GoF各模式原理及其优劣，会发现没有完美的模式，只有适合的模式， 这些模式只是前人帮我们总结好的问题解决方案之一，不是唯一， 我们要学习不禁是这个答案，更多的是解决问题的思维方式。 相较来说，几大设计原则是更具通用性的， 我们在GoF 里的很多模式上都可以看到设计原则的体现。

总结来说， 个人认为学习设计模式的重点是理解原理， 各模式解决的问题有个印象，在遇到类似问题，能想起来有这样的模式， 能快速查找相关资料，并确定是否直接使用模式或变形使用。 对相关类图更是没有必要死记，现实工作中完全可以现查，并且往往现实业务中不能完全套用，而需在符合设计原则情况下优化调整。