前言

对于设计模式，相信很多开发者并不陌生，我在学习过程中希望把自己的一些总结和心得体会与你分享。
本专栏主要将重点放在设计模式在游戏中的应用，会结合大家熟悉的游戏场景和功能阐述设计模式在该处应用的好处。因为设计模式很多，而且许多其实在游戏中并不会有应用空间，所以部分设计模式并不会出现在本专栏中，如果是希望学习所有设计模式的同学可以去寻找其他更优质的文章。
这是我开的第几个坑了？~~咕咕咕~~ 如今已经找到工作并且现在工作也已稳定，虽然加班很多，但是我还是希望把业余时间投入到文章创作之中，会努力把之前的坑给填上的。

1. 设计模式概述

1.1 设计模式的定义

设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且保证代码可靠性。

1.2 设计模式七大原则（概述）

1.2.1 单一职责原则(Single Responsibility Principle, SRP)

一个类只负责一个功能领域中的相应职责

1.2.2 开闭原则(Open-Closed Principle, OCP)

软件实体应对扩展开放，而对修改关闭

1.2.3 里氏代换原则(Liskov Substitution Principle, LSP)

所有引用基类对象的地方能够透明地使用其子类的对象

1.2.4 依赖倒转原则(Dependence Inversion Principle, DIP)

抽象不应该依赖于细节，细节应该依赖于抽象

1.2.5 接口隔离原则(Interface Segregation Principle, ISP)

使用多个专门的接口，而不使用单一的总接口

1.2.6 合成复用原则(Composite Reuse Principle, CRP)

尽量使用对象组合，而不是继承来达到复用的目的

1.2.7 迪米特法则(Law of Demeter, LoD)

一个软件实体应当尽可能少地与其他实体发生相互作用

1.3 设计模式的内容

设计模式一般包含模式名称、问题、目的、解决方案、效果等组成要素，其中关键要素是模式名称、问题、解决方案和效果。

1.3.1 模式名称(Pattern Name)

通过一两个词来描述模式的问题、解决方案和效果，以便更好地理解模式并方便开发人员之间的交流，绝大多数模式都是根据其功能或模式结构来命名的（GoF设计模式中没有一个模式用人名命名，）；

1.3.2 问题(Problem)

描述了应该在何时使用模式，它包含了设计中存在的问题以及问题存在的原因；

1.3.3 解决方案(Solution)

描述了一个设计模式的组成成分，以及这些组成成分之间的相互关系，各自的职责和协作方式，通常解决方案通过UML类图和核心代码来进行描述；

1.3.4 效果(Consequences)

描述了模式的优缺点以及在使用模式时应权衡的问题。

1.4 设计模式的分类

1.4.1 创建型模式：

工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

1.4.2 结构型模式：

适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

1.4.3 行为型模式：

策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

3. 设计模式七大原则

3.1 单一职责原则(Single responsibility principle)

一个类应该只负责一项职责。

3.2 接口隔离原则(Interface Segregation Principle)

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。

3.3 依赖倒转原则(Dependence Inversion Principle)

依赖倒转(倒置)的中心思想是面向接口编程，所谓“倒转”是指抽象不应该依赖细节，而是细节应该依赖抽象。也就是高层模块不应该依赖低层模块，二者都应该依赖其抽象。因为相对于细节的多变性，抽象的东西要稳定的多。

3.4 里氏替换原则(Liskov Substitution Principle)

所有引用基类的地方必须能透明地使用其子类的对象。也就是在继承关系中，子类尽量不要重写父类的方法。继承实际上让两个类耦合性增强了，特别是运行多态比较频繁的时，整个继承体系的复用性会比较差。
比如一种极端情况：一个类继承了另一个类，但却重写了所有方法，那么继承的意义何在？说好的复用呢？
解决方法是把原来的父类和子类都继承一个更通俗的基类，在适当的情况下，可以通过聚合，组合，依赖等来代替。

3.5 开闭原则(Open Closed Principle)

一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。也就是当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。用抽象构建框架，用实现扩展细节。
开闭原则是编程中最基础、最重要的设计原则。编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

3.6 迪米特法则(最少知识原则)(Demeter Principle)

即一个类对自己依赖的类知道的越少越好，核心是降低类之间的耦合。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public 方法，不对外泄露任何信息。
避免与非直接朋友的耦合，只与直接的朋友通信，所谓的直接朋友是出现成员变量，方法参数，方法返回值中的类。而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。