Unity游戏开发——设计模式概述

kccsong

0.前言

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

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

解决一再出现的问题

提出解决一般化问题的方案

使解决方案可以重复使用

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

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

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

需要一个极其稳定的框架来承载千万级用户

不断增加的游戏系统

对现有游戏功能的修改

敏捷开发

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

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

单一职责原则

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

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

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

开闭原则

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

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

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

里氏替换原则

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

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

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

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

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

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

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

举个栗子