面向对象设计原则

面向对象设计原则

1. 0单一职责原则（SRP）Single responsibility principle

1. 一个类最好只有一个职责
2. 如果他承担了多个职责会产生很多引起他变化的原因
3. 就一个类而言，应该仅有一个引起他变化的原因
4. 在SRP中职责定义为：变化的原因
5. 如果一个类承担的职责过多，就等于把这些职责耦合在了一起
6. 一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力
7. 耦合在了一起导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏
8. 优点以及例子

遵循单一职责原的优点有：

可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
提高类的可读性，提高系统的可维护性；
变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

 

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。

问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

 

 

1. 0开放封闭原则（OCP）Open-Closed Principle

1. OCP建议我们对系统进行重构
2. 我们可以对模块的功能进行改动和扩展
3. 对模块扩展时不改动源代码或者二进制代码
4. 优势：灵活性、可重用性以及维护性
5. 主要机制：抽象和多态
6. 支持抽象和多态的关键机制之一就是继承
7. OCP是OOD(面向对象设计方法)的核心
8. LSP是OCP成为可能的主要原则之一
9. 特性

符合开放封闭原则的模块都有两个主要特性：

1. 它们 "面向扩展开放（Open For Extension）"。

也就是说模块的行为是能够被扩展的。当应用程序的需求变化时，我们可以使模块表现出全新的或与以往不同的行为，以满足新的需求。

2. 它们 "面向修改封闭（Closed For Modification）"。

模块的源代码是不能被侵犯的，任何人都不允许修改已有源代码。

10.面对需求，对程序的改动是通过增加代码产生的，而不是更改现有的代码

11.简单的例子：一国两制

- 首先中国大陆的社会主义方针是坚定不移的

- 这时香港、澳门这两个在富人家过惯了的孩子又不肯回来过社会主义的生活

- 在不影响原有系统（大陆）的情况下，唯有对系统进行拓展

- 因此“一国两制”诞生了

1. 0 Liskov 替换原则（LSP）Liskov Substitution Principle

1. 子类必须能够替换掉他们的父类
2. 可以把公共的部分提出来，建一个超类，可以是抽象类
3. 完成功能少于其父类的子类通常不能替换父类
4. 问题：一个自相容的设计未必就和所有的用户程序相容
5. 基于契约设计：再重新声明派生类中的例程（routine）时，只能使用相等或者更弱的前置条件来替换原始的前置条件，只能使用相等或者更强的后置条件来替换原始的后置条件
6. 用提取公共部分的方法代替继承，使得父类的模块无需改动即可扩展
7. 子类型的正确定义是“可替换性的”
8. 例子：放在今天，刘德妃一定是面向对象的高手。她深谙“里氏替换原则”：

- 先创建“父类”– 孕妇，孕妇有两大特征：怀孕、生娃。

- 然后创建两个孕妇的实例：刘德妃和李姓侍女。

- 最后在运行时，用自己替换了真正的孕妇李侍女，成功欺骗了皇上。

之所以能够在运行时动态替换，是因为刘德妃的行为里完全继承了孕妇的特征。

 

 

1. 0依赖倒置原则（DIP）Dependency Inversion Principle

1 . 高层模块不应该依赖于低层模块。二者都应该依赖于抽象

1. 抽象不应该依赖于细节，细节应该依赖于抽象
2. “面向接口编程”—OOD(Object-Oriented Design，面向对象设计)的精髓之一。
3. 细节和抽象被彼此隔离更好维护，细节和策略都依赖于抽象
4. 它是实现开闭原则的重要方法

依赖倒置原则在java语言中，表现是：

• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
• 接口或抽象类不依赖实现类
• 实现类依赖接口或抽象类

 

1. 依赖倒置原则的经验

依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。我们在项目中使用这个原则要遵循下面的规则：

 

每个类尽量都有接口或者抽象类，或者抽象类和接口两都具备

 

变量的表面类型尽量是接口或者抽象类

 

任何类都不应该从具体类派生

 

尽量不要覆写基类的方法

如果基类是一个抽象类，而这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会有一定的影响。

 

结合里氏替换原则使用

里氏替换原则：父类出现的地方子类就能出现。结合本章我们得出了一个通俗的规则：接口负责定义public属性和方法，并且声明与其他对象的依赖关系。抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

8.在实际编程中，我们一般需要做到如下3点：

低层模块尽量都要有抽象类或接口，或者两者都有。

变量的声明类型尽量是抽象类或接口。

使用继承时遵循里氏替换原则。

 

依赖倒置有三种方式来实现

通过构造函数传递依赖对象；

比如在构造函数中的需要传递的参数是抽象类或接口的方式实现。

通过setter方法传递依赖对象；

即在我们设置的setXXX方法中的参数为抽象类或接口，来实现传递依赖对象。

接口声明实现依赖对象，也叫接口注入；

即在函数声明中参数为抽象类或接口，来实现传递依赖对象，从而达到直接使用依赖对象的目的。

 

8.为方便理解，举一些生活中的例子：

 1、AGP插槽。主板和显卡之间关系的抽象。主板和显卡通常是使用AGP插槽来连接的，这样，只要接口适配，不管是主板还是显卡更换，都不是问题。

 2、驾照。司机和汽车之间关系的抽象。有驾照的司机可以驾驶各种汽车。

  3、电源插座。

 

9.设计模式中最能体现DIP原则的是抽象工厂模式。

 在抽象工厂模式中，工厂和产品都可以是抽象的，如果客户要使用的话，只要关注于工厂和产品的接口即可，不必关注与工厂和产品的具体实现。

 

 

 

DIP对于并行开发的影响：两个类之间有依赖关系，只要制定出他们之间的接口，就可以并行开发了。

 

1. 0接口隔离原则（ISP）Interface Segregation Principle

1. 内聚：是一个模块内部各成分之间相关程度的度量（交互程度）
2. 胖接口定义：类的接口不内聚
3. 不应该强迫客户依赖于他们不用的方法
4. 根据客户所调用的服务方法来对客户进行分组
5. 可通过增加新接口的方法来缓解
6.  

接口隔离有两种定义：

客户端不应该依赖它不需要的接口

那依赖什么呢？依赖它需要的接口，客户端需要什么接口就提供什么接口，把不需要的接口剔除，那就需要对接口进行细化，保证其纯洁性。

类间的依赖关系应该建立在最小的接口上

它要求是最小的接口，也是要求接口细化，接口纯洁。

我们把两种定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗的说就是接口尽量细化，同时接口中的方法尽量少。

那么什么是接口：

接口分为两类：

实例接口(Object Interface)

在java中声明一个类，类也是一种接口。

类接口(Class Interface)

java中经常使用Interface来定义。

1. 1

接口隔离原则开发经验

接口隔离原则是对接口的定义，同时也是对类的定义，接口和类尽量使用原子接口或原子类来组装。我们在实践中可以以下几个规则来衡量：

 

 

一个接口只服务于一个子模块或业务逻辑

通过业务逻辑压缩接口中的public方法，接口要不断的精简，以达到接口不断完善

已经被污染的接口，尽量去修改，若变更的风险较大，则采用适配器进行转化处理