六大设计原则-单一职责原则

六大设计原则-单一职责原则

 

一.单一职责原则简介：

就一个类而言，应该仅有一个引起它变化的原因。简单的说，就是一个类只负责一项职责（功能）。

英文名：Single Responsibility Principle

___含义之一：避免相同的职责（也称为功能）分散到不同的类中实现。

___含义之二：也应该要避免一个类承担过多的职责，将过多的职责耦合在一个类中导致了脆弱设计。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。

二.单一职责原则分析：

1.一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小。而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。

2.类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现。

3。单一职责原则是实现高内聚、低耦合的指导方针，在很多代码重构手法中都能找到它的存在，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

三.Unity 项目单一职责

1.在Unity 项目开发过程中，有两个切入点：
___类功能的单一性；
___方法功能的单一性；
一个类只负责一件具体的事情，一个方法只完成一个特定的功能。当你发现一方法完成了两件事情的时候，就需要适当的重构成两个方法，类也是一样的。

在一个项目当中，总有一些脚本文件是相对而言比较庞大的，功能是比较复杂的，这些脚本如果你写完之后，不进行代码重构，往往就会比较臃肿，且不会符合单一职责原则。

2.在Unity 引擎内有一组灯光组件，是用于实现灯光照射渲染功能的，它根据不同的功能分割成了4 个组件：
方向光，点光源，聚光灯，区域光
虽然说4 个组件合并为一个，就叫做“灯光组件”，也是可以的，但是会比较臃肿，不方便使用。

3.资源管理
Unity 项目开发过程中，Assets 资源的管理，也是需要准守“单一职责原则”。
①每一类资源的文件夹分类；
②脚本按功能类别分类。

4、抽取出方法中的相同点，做为父类， 其它需要调用的脚本继承这个类，将是不错的方法

如：游戏中分数的管理与显示，抽取一个数据类脚本做为父类，管理和显示/绘制脚本继承这个父类，干它们各自该干的事，减少了代码量的同时，使得整个逻辑更为清析

　　游戏中的背包系统，共有的名称，价格等属性抽取成为父类，武器，防具，消耗品等分别继承自这个父类，又重构出各自的特色，