0.前言

这一系列的文章其实应该算作几本书和一些资料总结的笔记，是有关设计模式与游戏开发之间的应用。笔者将阅读学习过程中的思考和总结记录下来，也希望能提供给同样在这方面有疑问的朋友一些帮助。

1.设计模式是什么

首先我们要知道，设计模式是按照了“面向对象设计的原则”，强调了以类、对象、继承、组合作为软件设计分析的方式，提出了同类问题的解决方案，并主要满足了以下几点要求

• 解决一再出现的问题
• 提出解决一般化问题的方案
• 使解决方案可以重复使用

简而言之，设计模式重点在于“模式”二字，它如同开加盟店时，提供了一套可重复使用的策略，从选址、装修、供货渠道等，并且可以快速扩张。

同理当软件开发者遇到相同问题时，不必再思考如分析和设计，可以从设计模式中直接找到对应的解决方法直接使用。这样一来，既缩短了开发时间，又加强了软件的稳定性和维护性。

2.游戏开发与设计模式

在游戏开发中，我们会面临很多问题，如下

• 需要一个极其稳定的框架来承载千万级用户
• 不断增加的游戏系统
• 对现有游戏功能的修改
• 敏捷开发

这时，我们便需要用到设计模式，因为他是先人的智慧、是已经被验证过的模式、不必思考新的解决方案。

设计模式已经成为了软件设计领域的共同语音，所以他还可以给我们减少人与人之间沟通的误解，可以直接指明该游戏系统是用了什么设计模式，对于小型的游戏团队，更是提升了系统的稳定性和扩展性。

3.七大设计原则

单一职责原则

这个原则强调的是“当设计封装一个类时，该类应该只负责一件事”

说起来好像很简单，实际上对功能的划分通常也是开发者最头疼的一件事。

解决方案就是对类进行不断的重构，将部分功能抽成新的类，再利用组合的方式将新的类加入到原来的类中，慢慢的就会变成一个类只负责单一功能的实现。

开闭原则

这个原则强调的是“一个类应该对扩展开放，对修改关闭”

具体来说，对于已经完成测试或者上线运营的功能，我们不应该再修改这个类的任何接口或者实现内容，但是应该对功能的增加保持开放。

为了满足这个原则的要求，我们需要将“方法”上升到接口，将“实现”下放到子类中，这样当新增一个需求时，我们重新实现一个子类继承自接口或者旧的子类，然后在新的子类中新增功能，这样就保证了旧的功能没有发生变化（对修改关闭），同时新增了功能（对扩展开放）。

里氏替换原则

这里强调的是“子类必须能够替换父类”

关于这个概念，一般书中介绍的都比较抽象，也曾将困扰了许多人。笔者在此结合多方资料，说一下自己的理解。

首先里氏替换原则是继承复用的基础，反映了父类与子类之间的关系。

通俗的讲有父类的地方，全部替换成子类，不影响程序的运行，这样就满足里氏替换原则。

那什么样的子类在替换父类时，不会影响程序运行呢？

这种子类可以扩展父类的功能，但不能修改父类的原有功能。这也是对单一职责原则的补充——对扩展开放，对修改关闭。

如果违背了里氏替换原则，会让程序出错的概率大大提升

举个栗子

我们定义了一个父类——鸟，并且带有一个方法可以返回鸟的飞行高度。再定义两个子类：麻雀、企鹅，并且企鹅重写了返回飞行高度的方法，使得返回值为0。当外部需要获取所有鸟类的飞行高度，并作为除数的分母使用，我们都知道0不可以作为分母，这时程序便出错了。

这个栗子便出现了“子类修改父类原有功能”的禁忌，违反了里氏替换原则，也就是不能采用继承结构，要重新设计他们之间的关系。

依赖倒置原则

这个原则包含了两个主题

• 高层模块不能依赖于底层模块，两者都应该依赖于抽象概念
• 抽象接口不应该依赖于实现，而实现应该依赖于抽象接口

这里的抽象概念，我理解为接口，所以这是在告诉我们，要面向接口编程，不要面向实现方式编程。

那为什么我们要面向接口编程呢，这里我举一个实际生活中的栗子

我们的电脑就是高层模块，各种硬件设备就是底层模块，我们每增加一个硬件设备（底层模块），电脑（高层模块）就需要设计一个新的接口来兼容设备，这样便是高层模块依赖于底层模块，并且这并没有满足开闭原则，因为每次新增设备，都要对电脑进行修改。但是如果电脑定义了一个通用接口，每个硬件设备都遵循了接口协议，大家都可以插到同一个接口上，那电脑便不再依赖硬件设备了，并且两者现在都只需要跟中间层接口沟通就好，这也就是两者都依赖于抽象概念。

所以从这里我们能看出，依赖导致原则也是实现开闭原则的重要途径之一，他的目的是通过面向接口编程，来降低类与类之间的耦合。

接口隔离原则

这里强调的是“客户端不应该被迫使用他们用不到的接口方法”

其实就是要求我们对各个类，建立他们专用的接口，而不要试图去建立一个庞大的接口提供给所有需要他的类去调用它。

最少知识原则（迪米特法则）

定义上说，一个类应该对其他类拥有最少的知识

翻译成人话就是，如果两个类之间无需直接通信，那就不要互相调用，交给第三方转发就好了

举个栗子

公司老板不需要跟公司每个员工都直接交流，他只需要跟项目经理交流就好，由项目经理负责传达老板的指示，这样老板就拥有了对其他员工最少的知识，解除了对每个员工的依赖（耦合），现在他只依赖于项目经理。至于基层人员，当然可以说开就开喽。

但是在使用迪米特法则的时候需要反复权衡，如果使用不当，会产生大量中介类，使项目结构变的混乱。

合成复用原则

其实合成复用原则讲的就是如果可以用组合解决问题，就不用继承。

也就是组合优于继承。

为什么组合会优于继承呢？

首先，如果使用了继承，子类重写了父类方法，就会违背里氏替换原则，会让程序增加出错的可能。这里合成复用原则和里氏替换原则又是相辅相成的。

其次，使用继承，子类会依赖于父类的实现，这不利于类的扩展和实现。

最后，C#是无法使用多重继承的，使用组合的方式会比层层继承来的明白，利于项目的维护。

实现这个原则的方式也很简单，是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

4.总结

设计模式就是学习面向对象程序设计的最佳模版，它在我看来最终的目的都是通过解耦来提升程序的稳定性和扩展性，使用的手段包括提供中间层（接口）、划分职责、约定限制等。

而我们在游戏开发中，面临最多的问题在前期可能是大量的需求更改，中期要求敏捷开发，后期需要提供稳定的游戏框架支撑千万级用户，这都需要用到设计模式。

此篇是对设计模式笔记的一个开头，后面会总结常见的设计模式与游戏开发结合的案例，并且会提供Unity版本的实现方式。