结合unity项目开发浅谈设计模式的六大原则（二）

接着上一篇咱们接着往下讲：

 

3、依赖倒置原则

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

好比说一个中国人和一个外国人（日本人，德国人，俄罗斯人...）沟通：

中国人和外国人不直接沟通，中间须要一个翻译，中国人和外国人都依赖于翻译。

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

高层依赖于底层：开发游戏须要依赖于该平台的底层API。

由于编写这些游戏时，使用C#开发一个版本，稍做调整就能发布到N 个平台。

在咱们发布成不一样平台的游戏的时候，Unity 自己就作了一个“对接”的任务，把咱们的代码里面的API，对接到该平台上相应的API。

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

 

4、里氏转换原则

定义：①一个软件实体若是使用的是一个父类的话，那么必定适用于其子类。并且它察觉不出父类对象和子类对象的区别。

②在软件里面，把父类都替换成它的子类，软件的行为没有变化；通俗点说，子类型必须可以替换掉它们的父类型。

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

小米这个品牌的产品有不少，好比：手机，电视，笔记本电脑，空气净化器......

这些产品就比如是继承了父类之后，实现的子类。

[如下三句伪代码，就是里氏转换原则在代码中最多见的体现]

小米品牌mi = new 小米手机(); ① ②

小米手机m5 = new 小米手机(); ②

小米手机m4 = (小米手机)mi; ③

切入点：

①子类对象能够直接赋值给父类变量；

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

②子类对象能够调用父类中的成员，可是父类对象永远只能调用本身的成员；

理解：小米手机能够打电话，还能能使用小米公司的售后服务；可是小米公司不能打电话，它只能折腾本身的用户体验，设计理念，品牌定位，营销策略......

③若是父类对象中装的是子类对象，能够将这个父类对象强转为子类对象；

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

 

从unity引擎做为切入点理解：Unity 引擎是一个父类；

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

 

5、迪米特原则（又叫最少知识／知道原则）

定义：①若是两个类没必要彼此直接通讯，那么这两个类就不该当发生直接的相互做用。

若是其中一个类须要调用另一个类的某一个方法的话，能够经过第三者转发这个调用。

②一个对象应当对其余对象有尽量少的了解。

 

例如：普通人，银行，银行工做人

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

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

普通人与银行这两个类是彻底独立的，由银行工做人员这个类，完成两者的沟通。

当普通人或者银行发生了代码逻辑改变，只会影响到中间的工做人员。

可是若是普通人和银行直接沟通，这样耦合度就提升了，下降了普通人以及银行这两个类的复用性[普通人可能还须要和其余几十个相似于银行的机构沟通]。

 

1.编程中的切入点

①在类的结构设计上，每个类都应当尽可能下降成员的访问权限。

Unity 项目开发，不要使用public 公开字段，而后面板拖拽资源赋值这种方式。应该把字段所有private 修饰，而后public 属性公开调用。

②迪米特原则主要是强调了类与类之间的松耦合。

类与类之间的耦合度越低，越有利于代码的复用，一个处于低耦合的类被修改了，不会对有关系的类形成影响。

2.Unity 迪米特原则

 

在Untiy4.x 时代：

咱们建立一个脚本，挂载到游戏物体身上，该脚本内就有一堆属性可使用。

transform，rigidoby，light，audio，collider.......

经过这些属性，就能够直接调用当前游戏物体身上的对应的其余组件。

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

在Untiy5.x 时代：

这些属性98%都废弃掉了，只留了一个transform 属性，用于访问当前游戏物体身上的Transform 组件。访问其余的组件，必须先获取，再访问。

 

6、接口隔离原则（这里默认了解面向对象的继承，以及接口等相关语法格式）

定义：①客户端不该该依赖它不须要的接口；

②一个类对另外一个类的依赖应该创建在最小的接口上。

 

公司内有不少部门，好比：开发部，业务部，财务部等等，每一个部门内都有N个员工在工做。如今我把员工要作的事情，定义成一个接口，全部员工都实现这个接口去作事情。

这个接口中定义的事情有：

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

全部的员工都实现这个接口，去作事情。如今问题就出现了，不论是哪一个部门的员工，在实现了这个接口后，都有不少事情是不须要本身去作的。

当前这个接口就比较臃肿，咱们须要对接口进行“功能隔离”：

财务部员工接口：

工资计算，帐务管理；

业务部员工接口：

客户扩展，客户维护，产品推销；

开发部员工接口：

程序开发，软件维护；

这样对接口功能隔离，细分红不一样部门的职责功能接口，不论是现有的员工，仍是之后新加入的员工，只须要实现本身部门对应的接口便可。

 

1.切入点

接口要尽可能小。

在定义接口的时候，接口内的方法要尽可能的少，避免接口过于臃肿。

一个类因为功能上的需求，须要实现一个接口，要保证该接口内全部的方法，都是该类所须要的。

 

2.Unity 接口隔离原则

好比UGUI 中，就有不少接口能够用于对UI 游戏物体进行功能扩展。

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