引言
引言
面向对象设计模式（以下简称设计模式）是一个老生常谈的话题了，它是程序员的必修课，被称为“程序员的内功心法”，可见其是多么重要。
提起设计模式，我这里就不得不多说几句废话。我第一次接触到“设计模式”这个词是在大一的“面向对象程序设计”课上，依稀记得当时老师只讲了“单例模式”和“策略模式”等几个常见的模式。虽然没多少东西，却把我搞得云里雾里，完全不知道自己在干什么。
到了暑假实训的时候，我亲自设计并且实现了一个小型的MIS系统，虽然自我感觉非常良好，但当老师问到用了什么设计模式的时候，我是一句话也说不上来，场面极度尴尬，搞得我有点怀疑人生。
本来以为只有我智商掉线，可事实并非如此。事后我向其他同学问了问，发现他们和我没有任何区别，被问到设计模式时都是
设计模式是什么
设计模式到底是个什么东西？它为什么这么玄？这么多人都搞不懂它？要解释设计模式是什么，首先要解释“模式”这个词。
“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。”著名的建筑师Christopher Alexander如是说。虽然他所说的是建筑模式，但在程序设计里依然适用。
通俗地讲，模式就是“套路”，是某类重复发生的问题的“通解”。一般来讲，当某类问题反复出现时，人们就会去寻找“特效药”，专门来针对这类问题。所以，模式并非客观存在，而是人脑的主观产物。拿英雄联盟举例，上野中下辅的布局（EU流）就是一种模式，它实现了资源获取的最大化。然而，EU流打法并不是上帝教给人类的，在S1赛季，如何选择阵容并没有一个固定说法，直到S1世界总决赛FNC采用EU流打法拿了冠军之后，这种打法才逐渐形成了模式。
综上所述，模式就是人类在长期的实践中总结出来的经验，它并没有我们想象中那么玄乎其玄。
理解了模式是什么，也就理解了设计模式是什么。既然模式就是套路，那设计模式自然就是设计的套路咯。
《设计模式》第二页中对设计模式的定义如下：
一般而言，一个模式有四个基本要素：
- 模式名称（pattern name） 一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。
- 问题(problem) 描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。
- 解决方案(solution) 描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
- 效果(consequences) 描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。
为什么需要设计模式
初学者一定会有这样的想法：我随便写也能实现功能，为什么还要提出设计模式呢？
首先需要声明的是，出现这种想法对于初学者来说是很自然很正常的。这是因为初学者没有实战经验，没有遇到过各种问题，也就无法理解一个模式的problem部分。而这部分恰恰是设计模式存在的必要性的体现，不理解这里，自然也就觉得设计模式没有存在的必要了。
设计模式的提出一是为了给高频问题提供通解，从而避免重复劳动；二是为了定义一些术语，方便以后的交流。我可以非常肯定地说，如果没了设计模式，软件开发工作中会多出无数的重复工作，从业人员的交流也会变得异常困难，整个行业的发展速度会被严重拖慢。这就是我们为什么需要设计模式。
如何学好设计模式
很多人反复学习设计模式，却发现并没有什么卵用，总感觉似懂非懂，实际编码工作中也驾驭不了，包括我自己。对此，我总结了以下几点原因：
- 基础不牢。设计模式中大量使用了面向对象的几大特性，尤其是多态性。如果对面向对象理论的理解不到位，很可能会给设计模式的学习带来困难。
- 选择性屏蔽。前两次学设计模式时，我都是只关注solution，却忽视了problem，我相信很多人也和我一样。这是造成我们似懂非懂无法驾驭设计模式的罪魁祸首——我们根本不知道它有啥用，又何谈驾驭！
- 缺乏实战经验。套路这种东西，只有亲自踩过坑的人才能认同。初学者没有那么多的实战经验，没有遇到过诸多问题，自然也就很难认同模式中的做法。
个人认为，自己踩坑是学设计模式的最好方式。敲了小十万行代码后，我终于意识到了一件事：有些坑只有自己踩了才能记住。在自己动手写代码的同时，一定会遇到模式中提到的高频问题。我们会尝试用各种方法去解决这些问题，然后发现自己真是菜的鸭皮。在无数次踩坑碰壁，弄得遍体鳞伤之后，再去研究这些既有的模式，才能够体会到它们的优美之处，真正发自内心地接受它们。
关于本专栏
- 本专栏的参考文献是GoF的《设计模式——可复用面向对象软件的基础（第三版）》（以下简称《设计模式》），所有术语都以本书为准。
- 本专栏分为三期，第一期逐一介绍《设计模式》中总结的23种基本设计模式（也叫GoF设计模式），最后进行比较，第二期介绍GoF设计模式结合非面向对象编程范式形成的变体，第三期介绍基本设计模式的组合应用以及主流的几种高级设计模式。
- 本专栏放出的代码均为C#代码。
- 本专栏只是一个本科生的学习记录，并非教科书，难免存在错误，大神轻喷。
