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