0.前言
这一系列的文章其实应该算作几本书和一些资料总结的笔记，是有关设计模式与游戏开发之间的应用。笔者将阅读学习过程中的思考和总结记录下来，也希望能提供给同样在这方面有疑问的朋友一些帮助。
1.设计模式是什么
首先我们要知道，设计模式是按照了“面向对象设计的原则”，强调了以类、对象、继承、组合作为软件设计分析的方式，提出了同类问题的解决方案，并主要满足了以下几点要求
解决一再出现的问题提出解决一般化问题的方案使解决方案可以重复使用
简而言之，设计模式重点在于“模式”二字，它如同开加盟店时，提供了一套可重复使用的策略，从选址、装修、供货渠道等，并且可以快速扩张。
同理当软件开发者遇到相同问题时，不必再思考如分析和设计，可以从设计模式中直接找到对应的解决方法直接使用。这样一来，既缩短了开发时间，又加强了软件的稳定性和维护性。
2.游戏开发与设计模式
在游戏开发中，我们会面临很多问题，如下
需要一个极其稳定的框架来承载千万级用户不断增加的游戏系统对现有游戏功能的修改敏捷开发
这时，我们便需要用到设计模式，因为他是先人的智慧、是已经被验证过的模式、不必思考新的解决方案。
设计模式已经成为了软件设计领域的共同语音，所以他还可以给我们减少人与人之间沟通的误解，可以直接指明该游戏系统是用了什么设计模式，对于小型的游戏团队，更是提升了系统的稳定性和扩展性。
3.七大设计原则
单一职责原则
这个原则强调的是“当设计封装一个类时，该类应该只负责一件事”
说起来好像很简单，实际上对功能的划分通常也是开发者最头疼的一件事。
解决方案就是对类进行不断的重构，将部分功能抽成新的类，再利用组合的方式将新的类加入到原来的类中，慢慢的就会变成一个类只负责单一功能的实现。
开闭原则
这个原则强调的是“一个类应该对扩展开放，对修改关闭”
具体来说，对于已经完成测试或者上线运营的功能，我们不应该再修改这个类的任何接口或者实现内容，但是应该对功能的增加保持开放。
为了满足这个原则的要求，我们需要将“方法”上升到接口，将“实现”下放到子类中，这样当新增一个需求时，我们重新实现一个子类继承自接口或者旧的子类，然后在新的子类中新增功能，这样就保证了旧的功能没有发生变化（对修改关闭），同时新增了功能（对扩展开放）。
里氏替换原则
这里强调的是“子类必须能够替换父类”
关于这个概念，一般书中介绍的都比较抽象，也曾将困扰了许多人。笔者在此结合多方资料，说一下自己的理解。
首先里氏替换原则是继承复用的基础，反映了父类与子类之间的关系。
通俗的讲有父类的地方，全部替换成子类，不影响程序的运行，这样就满足里氏替换原则。
那什么样的子类在替换父类时，不会影响程序运行呢？
这种子类可以扩展父类的功能，但不能修改父类的原有功能。这也是对单一职责原则的补充——对扩展开放，对修改关闭。
如果违背了里氏替换原则，会让程序出错的概率大大提升
举个栗子
我们定义了一个父类——鸟，并且带有一个方法可以返回鸟的飞行高度。再定义两个子类：麻雀、企鹅，并且企鹅重写了返回飞行高度的方法，使得返回值为0。当外部需要获取所有鸟类的飞行高度，并作为除数的分母使用，我们都知道0不可以作为分母，这时程序便出错了。
这个栗子便出现了“子类修改父类原有功能”的禁忌，违反了里氏替换原则，也就是不能采用继承结构，要重新设计他们之间的关系。
依赖倒置原则
这个原则包含了两个主题
高层模块不能依赖于底层模块，两者都应该依赖于抽象概念抽象接口不应该依赖于实现，而实现应该依赖于抽象接口
这里的抽象概念，我理解为接口，所以这是在告诉我们，要面向接口编程，不要面向实现方式编程。
那为什么我们要面向接口编程呢，这里我举一个实际生活中的栗子
我们的电脑就是高层模块，各种硬件设备就是底层模块，我们每增加一个硬件设备（底层模块），电脑（高层模块）就需要设计一个新的接口来兼容设备，这样便是高层模块依赖于底层模块，并且这并没有满足开闭原则，因为每次新增设备，都要对电脑进行修改。但是如果电脑定义了一个通用接口，每个硬件设备都遵循了接口协议，大家都可以插到同一个接口上，那电脑便不再依赖硬件设备了，并且两者现在都只需要跟中间层接口沟通就好，这也就是两者都依赖于抽象概念。
所以从这里我们能看出，依赖导致原则也是实现开闭原则的重要途径之一，他的目的是通过面向接口编程，来降低类与类之间的耦合。
接口隔离原则
这里强调的是“客户端不应该被迫使用他们用不到的接口方法”
其实就是要求我们对各个类，建立他们专用的接口，而不要试图去建立一个庞大的接口提供给所有需要他的类去调用它。
最少知识原则（迪米特法则）
定义上说，一个类应该对其他类拥有最少的知识
翻译成人话就是，如果两个类之间无需直接通信，那就不要互相调用，交给第三方转发就好了
举个栗子
公司老板不需要跟公司每个员工都直接交流，他只需要跟项目经理交流就好，由项目经理负责传达老板的指示，这样老板就拥有了对其他员工最少的知识，解除了对每个员工的依赖（耦合），现在他只依赖于项目经理。至于基层人员，当然可以说开就开喽。
但是在使用迪米特法则的时候需要反复权衡，如果使用不当，会产生大量中介类，使项目结构变的混乱。
合成复用原则
其实合成复用原则讲的就是如果可以用组合解决问题，就不用继承。
也就是组合优于继承。
为什么组合会优于继承呢？
首先，如果使用了继承，子类重写了父类方法，就会违背里氏替换原则，会让程序增加出错的可能。这里合成复用原则和里氏替换原则又是相辅相成的。
其次，使用继承，子类会依赖于父类的实现，这不利于类的扩展和实现。
最后，C#是无法使用多重继承的，使用组合的方式会比层层继承来的明白，利于项目的维护。
实现这个原则的方式也很简单，是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。
4.总结
设计模式就是学习面向对象程序设计的最佳模版，它在我看来最终的目的都是通过解耦来提升程序的稳定性和扩展性，使用的手段包括提供中间层（接口）、划分职责、约定限制等。
而我们在游戏开发中，面临最多的问题在前期可能是大量的需求更改，中期要求敏捷开发，后期需要提供稳定的游戏框架支撑千万级用户，这都需要用到设计模式。
此篇是对设计模式笔记的一个开头，后面会总结常见的设计模式与游戏开发结合的案例，并且会提供Unity版本的实现方式。
