Unity_面向对象设计原则_026

单一原则SRP

单一职责原则是最简单的面向对象设计原则，用于控制类的粒度大小

单一职责原则：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。

就一个类而言，应该仅有一个引起它变化的原因

一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小

当一个职责变化时，可能会影响其他职责的运作

将这些职责进行分离，将不同的职责封装在不同的类中

将不同的变化原因封装在不同的类中

单一职责原则是实现高内聚、低耦合的指导方针

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意向不到的破坏。

开闭原则OCP

开闭原则是面向对象的可复用设计的第一块基石，是最重要的面向对象设计原则

开闭原则：软件实体应当对扩展开放，对修改关闭。

开闭原则由Bertrand Meyer于1988年提出

在开闭原则的定义中，软件实体可以是一个软件模块、一个由多个类组成的局部结构或一个独立的类

开闭原则是指软件实体应尽量在不修改原有代码的情况下进行扩展

抽象化是开闭原则的关键

相对稳定的抽象层 + 灵活的具体层

对可变性封装原则(Principle of Encapsulation of Variation, EVP)：在你的设计中什么可能会发生变化，应使之成为抽象层而封装，而不是什么会导致设计改变才封装

一个软件实体应当对扩展开放，对修改关闭，也就是说在设计一个模块的时候，应当使这个模块可以在部内修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。

开闭原则面对需求，对程序的改动是通过增加新的代码来进行的，而不是改变原来的代码。（接口比较方便）

里氏转换原则LSP

子类必须能够替换掉他们的父类。

里氏代换原则：所有引用基类的地方必须能透明地使用其子类的对象。

子类可以扩展父类的功能，但不能改变父类原有的功能

里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士、麻省理工学院教授Barbara Liskov和卡内基.梅隆大学Jeannette Wing教授于1994年提出

在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象

在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型

我喜欢动物

我喜欢狗

因为狗是动物

依赖倒置原则DIP

高层模块不应该依赖底层模块，它们都应该依赖抽象，抽象不应该依赖于细节，细节应该依赖于抽象

要针对接口编程，不要针对于实现编程

依赖倒转原则：

A:高层模块不应该依赖低层模块，它们都应该依赖抽象。

B:抽象不应该依赖于细节，细节应该依赖于抽象。

要针对接口编程，不要针对实现编程

依赖倒转原则是Robert C. Martin在1996年为“C++ Reporter”所写的专栏Engineering Notebook的第三篇，后来加入到他在2002年出版的经典著作《Agile Software Development, Principles, Patterns, and Practices》一书中

在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等

在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中

针对抽象层编程，将具体类的对象通过依赖注入(Dependency Injection, DI)的方式注入到其他对象

构造注入

设值注入（Setter注入）

接口注入

接口隔离原则ISP

接口隔离原则：客户端不应该依赖那些它不需要的接口。

当一个接口太大时，需要将它分割成一些更细小的接口

使用该接口的客户端仅需知道与之相关的方法即可

每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干

“接口”定义(1)：一个类型所提供的所有方法特征的集合。一个接口代表一个角色，每个角色都有它特定的一个接口，“角色隔离原则”

“接口”定义(2)：狭义的特定语言的接口。接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口，每个接口中只包含一个客户端所需的方法，“定制服务”

合成复用原则CRP

合成复用原则：优先使用对象组合，而不是继承来达到复用的目的。

合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分

新对象通过委派调用已有对象的方法达到复用功能的目的

复用时要尽量使用组合/聚合关系（关联关系），少用继承

合成或组合（Composition）是一种强的拥有关系，体现了严格的部分和整体关系，部分和整体的生命周期是保持一致的

聚合（Aggregation）是一种弱的拥有关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。

个人的理解

合成的例子：大雁与大雁的翅膀，二者公存亡。比聚合的耦合关系更加强烈

聚合的例子：大雁与雁群，二者生命周期并不一致。

继承复用：实现简单，易于扩展。破坏系统的封装性；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；只能在有限的环境中使用。（“白箱”复用 ）

组合/聚合复用：耦合度相对较低，有选择性地调用成员对象的操作；可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。（“黑箱”复用 ）

迪米特法则LKP

迪米特法则又称为最少知识原则(Least Knowledge Principle, LKP)

迪米特法则：每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项目

迪米特法则要求一个软件实体应当尽可能少地与其他实体发生相互作用

应用迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系

不要和“陌生人”说话 (Don’t talk to strangers.)

只与你的直接朋友通信 (Talk only to your immediate friends.)

(1) 当前对象本身(this)

(2) 以参数形式传入到当前对象方法中的对象

(3) 当前对象的成员对象

(4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友

(5) 当前对象所创建的对象

任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”

在应用迪米特法则时，一个对象只能与直接朋友发生交互，不要和“陌生人”发生直接交互，这样做可以降低系统的耦合度，一个对象的改变不会给太多其他对象带来影响

迪米特法则要求在设计系统时，应该尽量减少对象之间的交互

如果两个对象之间不必彼此直接通信，那么这两个对象就不应该发生任何直接的相互作用

如果其中一个对象需要调用另一个对象的方法，可以通过“第三者”转发这个调用

通过引入一个合理的“第三者”来降低现有对象之间的耦合度

应用迪米特法则注意点：

在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大影响

在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限

在类的设计上，只要有可能，一个类型应当设计成不变类

在对其他类的引用上，一个对象对其他对象的引用应当降到最低

上述原则的作用：让自己设计实现出来的软件系统更加稳定，容易维护，并具有一致性。