unity 项目开发——浅谈设计模式的六大原则(二)

简介: unity 项目开发——浅谈设计模式的六大原则(二)

前言


       接着上一篇我们接着往下讲吧!

正文


三、依赖倒置原则


   定义:针对抽象编程,不要针对实现编程;高层模块不应该依赖于底层模块,两个模块都应该依赖于抽象 (抽象类 / 接口)。高层和底层不应该直接沟通,高层底层之间,应该有一个中间层,负责两方沟通。


       比如说一个中国外交官和一个外国大使(日本人,德国人,俄罗斯人...)对话:

外交官和外国大使不直接沟通,中间需要一个翻译,两人都依赖于翻译。

Unity 依赖倒置原则


 Unity 引擎是把 “依赖倒置原则” 玩的很溜的一款产品。


       高层依赖于底层:开发游戏需要依赖于该平台的底层 API。因为编写这些游戏时,使用 C# 开发一个版本,稍作调整就能发布到 N 个平台。


       在我们发布成不同平台的游戏的时候,Unity 本身就做了一个 “对接” 的任务,把我们的代码里面的 API,对接到该平台上相应的 API。


       高层和底层都依赖于抽象:我们的游戏是依赖 Unity 的,各个平台的 API 也是 Unity 完成对接任务的。

四、里氏转换原则


  定义:一个软件实体如果使用的是一个父类的话,那么一定适用于其子类。而且它察觉不出父类对象和子类对象的区别。在软件里面,把父类都替换成它的子类,软件的行为没有变化;通俗点说,子类型必须能够替换掉它们的父类型

 从生活层面中理解里氏转换原则,一个公司的品牌就好比是一个父类,小米这个牌子就是一个父类。


       小米这个品牌的产品有很多,比如:手机,电视,笔记本电脑,空气净化器......


       这些产品就好比是继承了父类以后,实现的子类。


       [以下三句伪代码,就是里氏转换原则在代码中最常见的体现]

小米品牌 mi = new 小米手机 (); 
小米手机 m5 = new 小米手机 (); 
小米手机 m4 = (小米手机) mi;

      切入点:


①子类对象可以直接赋值给父类变量;


理解:使用小米手机的用户就是小米公司的用户。


②子类对象可以调用父类中的成员,但是父类对象永远只能调用自己的成员;


理解:小米手机可以打电话,还能能使用小米公司的售后服务;但是小米公司不能打电话,它只能折腾自己的用户体验,设计理念,品牌定位,营销策略......


③如果父类对象中装的是子类对象,可以将这个父类对象强转为子类对象;


理解:小米公司开新产品发布会 --> 小米 6 手机发布会。

Unity 里氏转换原则


       从 unity 引擎作为切入点理解:Unity 引擎是一个父类;

       Unity4.x,Unity5.x,Unity2017.x 都是这个父类下的子类。本身具备父类的功能,同时又都有自己的新功能。

五、迪米特原则(又叫最少知识/知道原则)


  定义:如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用;如果其中一个类需要调用另外一个类的某一个方法的话,可以通过第三者转发这个调用;一个对象应当对其他对象有尽可能少的了解。

       例如:普通人,银行,银行工作人

在现实生活中,我们普通人不需要了解银行的各种体系规章制度,当我们普通人和银行发生业务关系的时候,我们面对的是银行的工作人员。工作人员完成了普通人与银行的沟通。

 而在编程中,普通人,银行,银行工作人员,会表现成三个类。

       普通人与银行这两个类是完全独立的,由银行工作人员这个类,完成二者的沟通。当普通人或者银行发生了代码逻辑改变,只会影响到中间的工作人员。

  但是如果普通人和银行直接沟通,这样耦合度就提高了,降低了普通人以及银行这两个类的复用性 [普通人可能还需要和其他几十个类似于银行的机构沟通]。

Unity 迪米特原则


   在 Untiy4.x 时代:

       我们创建一个脚本,挂载到游戏物体身上,该脚本内就有一堆属性可以使用。

transform,rigidoby,light,audio,collider.......

       通过这些属性,就可以直接调用当前游戏物体身上的对应的其他组件。

       但是 “它知道的太多了”,不管我们这个游戏物体身上有没有这些组件,这些属性都是存在的,不符合 “最少知道原则”。

   而在 Untiy5.x 时代:

       这些属性 98% 都废弃掉了,只留了一个 transform 属性,用于访问当前游戏物体身上的 Transform 组件。访问其他的组件,必须先获取,再访问。这正体现了迪米特原则。

六、接口隔离原则(这里默认了解面向对象的继承,以及接口等相关语法格式)


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

 公司内有很多部门,比如:

开发部,业务部,财务部等等,每个部门内都有 N 个员工在工作。

       而现在我把员工要做的事情,定义成一个接口,所有员工都实现这个接口去做事情。

     那么在这个接口中定义的事情有:

工资计算,账务管理,客户扩展,客户维护,产品推销,程序开发,软件维护。

       所有的员工都实现这个接口,去做事情。

     但是现在问题就出现了,不管是哪个部门的员工,在实现了这个接口后,都有很多事情是不需要自己去做的。

       当前这个接口就比较臃肿,我们需要对接口进行 “功能隔离”:

财务部员工接口:

工资计算,账务管理;

业务部员工接口:

客户扩展,客户维护,产品推销;

开发部员工接口:

程序开发,软件维护;

     这样对接口功能隔离,细分成不同部门的职责功能接口,不管是现有的员工,还是以后新加入的员工,只需要实现自己部门对应的接口即可。

Unity 接口隔离原则


   比如 UGUI 中,就有很多接口可以用于对 UI 游戏物体进行功能扩展。


       UGUI 中的 UI 事件,我们在编写 UI 控制脚本时,在继承了 Mono 行为类之后,还可以实现 N 个 UI 事件接口 [Interface]。这里涉及到的事件接口,它们的定义就是准守了接口隔离原则。

目录
相关文章
|
2月前
|
设计模式
设计模式七大原则
这篇文章介绍了设计模式中的七大原则,特别强调了单一职责原则,即一个类应该只有一个引起其行为变化的原因,以确保类功能的高内聚和低耦合。
|
2月前
|
设计模式 存储 前端开发
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
|
20天前
|
设计模式 Java 关系型数据库
设计模式——设计模式简介和七大原则
设计模式的目的和核心原则、单一职责原则、接口隔离原则、依赖倒转原则、里氏替换原则、开闭原则、迪米特法则、合成复用原则
设计模式——设计模式简介和七大原则
|
2月前
|
设计模式 算法 开发者
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
|
2月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
|
2月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
|
4月前
|
设计模式 uml
设计模式学习心得之前置知识 UML图看法与六大原则(下)
设计模式学习心得之前置知识 UML图看法与六大原则(下)
29 2
|
4月前
|
设计模式 Java 数据库
深入理解设计模式六大原则
深入理解设计模式六大原则
|
2月前
|
图形学 C#
超实用!深度解析Unity引擎,手把手教你从零开始构建精美的2D平面冒险游戏,涵盖资源导入、角色控制与动画、碰撞检测等核心技巧,打造沉浸式游戏体验完全指南
【8月更文挑战第31天】本文是 Unity 2D 游戏开发的全面指南,手把手教你从零开始构建精美的平面冒险游戏。首先,通过 Unity Hub 创建 2D 项目并导入游戏资源。接着,编写 `PlayerController` 脚本来实现角色移动,并添加动画以增强视觉效果。最后,通过 Collider 2D 组件实现碰撞检测等游戏机制。每一步均展示 Unity 在 2D 游戏开发中的强大功能。
83 6
|
1月前
|
测试技术 C# 图形学
掌握Unity调试与测试的终极指南:从内置调试工具到自动化测试框架,全方位保障游戏品质不踩坑,打造流畅游戏体验的必备技能大揭秘!
【9月更文挑战第1天】在开发游戏时,Unity 引擎让创意变为现实。但软件开发中难免遇到 Bug,若不解决,将严重影响用户体验。调试与测试成为确保游戏质量的最后一道防线。本文介绍如何利用 Unity 的调试工具高效排查问题,并通过 Profiler 分析性能瓶颈。此外,Unity Test Framework 支持自动化测试,提高开发效率。结合单元测试与集成测试,确保游戏逻辑正确无误。对于在线游戏,还需进行压力测试以验证服务器稳定性。总之,调试与测试贯穿游戏开发全流程,确保最终作品既好玩又稳定。
47 4