终于，我们要开始讨论设计模式了。 如果不知道什么是设计模式，不妨先看我的另一篇文章—— 有趣的反面模式 。 设计模式就是与反面模式相对的正面模式，它是一系列好的编程实践的集合，是一瓶瓶灵丹妙药，吃对了延年益寿，乱吃或者吃错了那就是走火入魔，毒火攻心。
现在业内，针对设计模式一词的态度基本上分为两类： 第一类，会觉得设计模式是个好东西，面试的时候会问求职者，平时工作的时候也会想方设法用起来，谈起设计模式似乎就是高大上的代名词。 第二类，会对设计模式深恶痛绝，觉得它提高了语言学习的门槛，编造多余的技术名词，还有人觉得设计模式害人不浅，根本没什么用或者反而会产生不良作用。设计模式就是毒瘤。
我认为上面两类看法都是错误的。 设计模式的确是个好东西，但是设计模式并不是什么银弹或者万能钥匙，设计模式就是很普通的概念，和面向对象编程，或者和数据结构一样，不过是编程领域的某个方面而已，如果要把编程编写成一本大百科全书，那么里面必然有属于设计模式的一个章节。
设计模式之所以会产生两极分化的看法，和设计模式本身异常复杂，很难被掌握有一定关系。它需要的不是简单机械的公式，也不是什么非0即1的算法，设计模式是一种经验，更是一种哲学。 编程在我看来，最难的不是什么算法，也不是什么数据结构或者语言用法，编程最难的在于程序员的内心，程序员的思维，他们对这个真实世界的抽象能力，他们对当前乃至未来的程序世界的架构能力。 显然，学习设计模式和这些能力有关。设计模式考验程序员的抽象能力，更考验程序员的架构能力。它提供给你许多许多的方法，原则，教条，经验，规律，而难点在于当你面对困难时，你并不知道该怎样选择。
我经常面对忘我学习而把食物放冷的困境，我的第一想法是凑合吃吃，但这样对胃不好，我的第二想法是拿去用锅热热，但是这样非常麻烦，我还要洗锅。尽管在半年前我已经买了微波炉，但是我经常忘记这件事，然后总是在准备起身去热食物的过程中看到它，然后想起来，哦，原来这里有一种更简单的办法。 设计模式的困境就是如此，我们有近百种设计模式，可是程序员的能力有限，他总是在事后才想起来，哦，有这么一种通用方法，可以解决我的问题。
有些人并不是这样，他们天生喜欢装饰自己，让自己显得比别人厉害，于是他们总是在事前就拿起设计模式，往自己将要写的代码上生搬硬套。别人问起来，总是拿设计模式的名气当做自己的挡箭牌。数月之后，危机显现，于是设计模式就变成了害人不浅的东西，被人人唾弃。
那些喷设计模式提高了语言学习门槛的，我也不能赞同。我认为设计模式并没有提高语言学习的门槛，而是编程语言本来就不是一件容易的事，不是学会了写ifelse之类的语法结构，就算是学会了编程。从某种意义上讲，设计模式是编程的进阶，当你学习编程学到一定深度时，设计模式讨论的问题，就不可避免地出现在你面前。就算前人没有总结出设计模式，你仍然要面对它们，面对这些通用的，经常会出现的情况。
这篇文章的目的很简单：
另外，这篇文章是基于JAVA设计模式的官方网站，github知名代码仓库{% link “java-design-patterns” https://github.com/iluwatar/java-design-patterns %}来编写的。尽量保证权威性。
第一章主要关注创建对象使用的模式，即创建型模式。
每个模式后面都会有推荐等级，下面统一介绍一下推荐等级含义： ★：一颗星，说明你应该尽量避免使用这种设计模式，它是小众设计模式，其复杂度远大于其带来的收益。 ★★：两颗星，代表你最好不要刻意使用该模式，它太小众或者说不常见。它所解决的问题你不看设计模式也可以轻松解决。 ★★★：三颗星，代表你可以在适用场景使用它，但是前提是你知道如何熟练地使用该设计模式。在非必须的场景下，你绝对不能使用该模式。 ★★★★：四颗星，代表你可以在适用场景使用它，但是前提是你知道如何熟练地使用该设计模式。在非必须的场景下，应该先尝试不使用该设计模式，若发现不使用无法满足需求，再使用。 ★★★★★：五颗星，代表在适用场景下，你应该尽量使用该设计模式