设计模式讲解与代码实践（零）——序

本文来自李明子csdn博客（http://blog.csdn.net/free1985），商业转载请联系博主获得授权，非商业转载请注明出处！

随着《设计模式讲解与代码实践（二十四）——访问者》的发表，《设计模式讲解与代码实践》这个专栏的更新也已经接近尾声。今天我将补写一个序，聊聊对设计模式的学习与工作中应用的一些心得体会。

1 我与设计模式

1.1 初识
因为学生阶段并没有设计模式的相关课程，我最初系统学习设计模式是在工作后的第三年即2011年。当时我自觉已经具备了基本的开发能力，希望在设计方面有所突破，于是很自然的接触到了经典教程《设计模式——可复用面向对象软件基础》，即《Design Patterns——Elements of Reusable Object-Oriented Software》。很快，我便被这本书所吸引，如饥似渴的精读了书中的全部内容并做了读书笔记。当时，我的主要开发语言是C++，我便用C++根据书中类图描述编写了全部示例。时至今日，我仍能回想起自己当年为书中的场景描述该如何实现而不思茶饭，最终为对应的设计模式解法拍案叫绝。
1.2 第二语言
因为工作关系，我在应用层开发方面先后学习和使用了C++、C#和JAVA三种语言。虽然同为面向对象开发语言，但语法和特性的差别在使用第二语言设计和开发的初期仍给我带来了困扰。此时，我想起了设计模式。于是，用第二语言重新实现各设计模式示例成了我快速掌握新语言的捷径。
1.3 团队培养
随着移动互联、微服务等短生命周期软件项目的兴起及全栈工程师、敏捷开发、开源框架等概念及工具的流行，人才市场的开发工程师越来越倾向于“项目型”而非传统意义上的“产品型”。2016年，我在为MDM产品招募开发人员过程中惊讶的发现能够熟练掌握和使用5种以上设计模式的中级开发工程师已经是凤毛麟角了。
在随后与同事及应聘者的交流中，我发现虽然很多开发者有设计模式的学习需求和学习欲望，但却对设计模式的学习无从下手。一些教程提供的示例要么由于业务场景过于专业难于理解要么代码过于复杂，混杂了多个设计模式难以剥离。
鉴于上述情况，我编写了这套教程作为开发组内部培训教程并在CSDN开创了这个专栏，分享给希望学习设计模式的开发者作为参考。

2 为什么学习设计模式

2.1 术语
对于软件设计师，设计模式是高效的沟通术语。当我们在设计文档中看到这个类为“单例”时，便勿需多言它该如何实现了。
另外，设计模式在实际的项目中被广泛应用。熟知各种设计模式对我们理解各种开源框架及类库的某些功能的实现大有裨益。
2.2 模板
就像我们在学写作文时的“总分总”结构一样，软件设计是有一些模板可以套用的。这从设计模式这个名称中便可见一斑。模仿与提高是任何技术学习的必经过程。模仿可以使我们站在巨人的肩膀上加速设计过程。很难想象在没有任何提示的情况下我们需要多久才能给出解释器设计模式这样的解决方案来高效的实现可重用的语法树求值。
2.3 业务抽象
面向对象语言中最基本也是最重要的概念便是抽象。从方法学的角度来讲，抽象也是我们能够复用已有知识及代码的基础。当我们对一个具体的业务需求进行建模后，便可以将其分解为与业务无关的设计需求。而设计模式提供了这些设计需求的解决方案。当我们在设计中希望使用设计模式时会不自觉的将业务需求转化为设计需求，从而提高对业务需求的抽象能力。

3 怎么学习设计模式

3.1 理解核心问题
如果将设计模式的类图全部汇总并去掉所有文字仅保留图形，我们会惊讶的发现设计模式无非是一个或几个类的继承与组合，有些设计模式的类图甚至是雷同的。那么我们学习设计模式的核心问题是什么？答案是如何将设计需求用类之间的关系正确的表达——即解决设计问题。比如，我们该如何解决大量的细粒度对象的创建？
3.2 模仿
2.2节中我提到了模仿给我们带来的好处。当我们学习了设计模式后，应该在自己的项目或开源项目中识别使用的设计模式，理解它是如何实现业务需求的，并在自己做设计时考虑是否遇到了类似的需求，是否也应该使用某种设计模式来解决该问题。
3.3 交流
闭门造车很难提高技术能力。这个结论适用于编码技术也适用于设计技术。如果你有幸置身于一个对设计有着严格要求，会做设计评审的开发组，那么请珍惜这个提高设计能力的机会；如果你所在的开发组没有这样的制度环境，没关系，相信你一定会在线下或线上，国内或国外找到愿意与你讨论你的设计的人。
3.4 练习
学习设计模式是为了学以致用。通常情况下我们是先有设计需求再去选择设计模式。其实，在学习阶段，我们可以反其道而行之。这并不难理解。比如我们在学习一个生字时便会通过组词造句来加深对这个生字的理解。对于设计模式这种假想式练习同样适用。试问我们能有多少实际的项目经验来覆盖这二十余种设计模式呢？而通过假想练习，我们可以在短时间内积累大量的设计模式“使用”经验，为即将到来的实际项目做好准备。
当我为了编写本教程而从生活中寻找素材，“设计”最恰当的业务场景时，那种对设计模式使用场景认识的提高是前所未有的。也许这恰恰印证了赠人玫瑰手有余香这句话吧。

4 写在最后

本套教程致力于结合最简单最易于理解的业务场景讲解设计模式。教程中所有的类图及设计模式参与者划分均来自《设计模式——可复用面向对象软件基础》。教程中所有场景示例均为笔者虚构，源码均为笔者原创，未借鉴参考任何教程及源码。
归根结底，设计模式为我们提供了各种抽象技术场景的解决方案。虽然设计模式为我们日常的设计工作提供了工具与指导，但并不是解决设计问题的万能药。在实际的业务场景中，如何灵活的使用和组合各种设计模式来解决设计问题才是对软件设计师的真正挑战。我们评价一个设计的优劣时，能够解决业务问题仅仅是最低标准。根据实际项目情况，权衡可读性、时间空间效率、可扩展性甚至考虑开发阶段、开发人员能力配比与并行开发等非技术因素提供最优解才是一个优秀的软件设计师应该追求的设计目标。然而，这一切，都需要扎实的理论基础、内在或外在的严格要求与长年累月的经验积累。
最后，希望本教程能够为学习设计模式的开发者提供一丝帮助。