设计模式–01–6原则
1、单一职责原则
1.1、优点
- 降低类的复杂度，一个类只负责一项职责。
- 提高类的可读性，可维护性
- 降低变更引起的风险。
1.2、违背单一职责原则情况
- 只有逻辑足够简单，才可以在代码级违反单一职责原则；
- 只有类中方法数量足够少，才可以在方法级别违反单一职责原则。
1.3、什么是单一职责
- 针对类，一个类应该只负责一项职责。
假设类T负责两个不同职责：P1，P2，当职责P1需求变更而改变T时，可能造成职责P2发生故障，所以需要将类T的粒度分解为T1，T2。
示例如下：
package com.example.demo.sixYuanZhe;
public class Test {
public static void main(String[] args) {
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("猪");
animal.breathe("鱼");
}
static class Animal {
public void breathe(String animal) {
System.out.println(animal + "呼吸空气");
}
}
}
我们发现不是所有动物都是呼吸空气的，比如鱼就是呼吸水的，根据单一职责原则，我们将Animal类细分为陆生动物类和水生动物类，如下所示：
public class Test2 {
public static void main(String[] args) {
Terrestrial terrestrial = new Terrestrial();
terrestrial.breathe("牛");
terrestrial.breathe("羊");
terrestrial.breathe("猪");
Aquatic aquatic = new Aquatic();
aquatic.breathe("鱼");
}
static class Terrestrial {
public void breathe(String animal) {
System.out.println(animal + "呼吸空气");
}
}
static class Aquatic {
public void breathe(String animal) {
System.out.println(animal + "呼吸水");
}
}
}
我们发现这样修改的花销很大，既要将原来的类分解，又要修改客户端。而直接修改Animal类虽然违背了单一职责原则，但花销小的多，如下所示：
public class Test3 {
public static void main(String[] args) {
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("猪");
animal.breathe("鱼");
}
static class Animal {
public void breathe(String animal) {
if ("鱼".equals(animal)) {
System.out.println(animal + "呼吸水");
} else {
System.out.println(animal + "呼吸空气");
}
}
}
}
可以看到，这种修改方式简单的多。但却存在隐患，一天需要将鱼分为淡水鱼，海水鱼，又需要修改Animal类的breathe方法。可能给"猪牛羊"等相关功能带来风险，这种修改直接在代码级别违背了单一职责原则，虽然修改起来最简单，但隐患最大。还有一种修改方式：
public class Test4 {
public static void main(String[] args) {
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("猪");
animal.breathe2("鱼");
}
static class Animal {
public void breathe(String animal) {
System.out.println(animal + "呼吸空气");
}
public void breathe2(String animal) {
System.out.println(animal + "呼吸水");
}
}
}
这种修改方式没有改动原来的方法，而是在类中新加了一个方法，这样虽然违背了单一职责原则，但在方法级别上却是符合单一职责原则的。
实际编程中原则
- 只要逻辑足够简单，就可以在代码级违反单一职责原则；
- 只要类中方法数量足够少，就可以在方法级别违反单一职责原则。
2、里氏替换原则
2.1、定义
如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。
换句话说，所有引用基类的地方必须能透明地使用其子类的对象。
总结：所有引用父类的地方 可以使用 子类的对象来替换
2.2、分析定义
- 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写和重载父类的方法。
2. 继承包含这样含义：父类中凡是已经实现好的方法（非抽象方法），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。
2.3、继承弊端（扩展）
- 使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。
2.3.1、继承的风险举例: 一个两数相减的功能，由类A来负责
public class Test5 {
public static void main(String[] args) {
A a = new A();
System.out.println("100-50=" + a.func1(100, 50));
System.out.println("100-80=" + a.func1(100, 80));
}
static class A {
public int func1(int a, int b) {
return a - b;
}
}
}
后来，我们需要增加一个新的功能：完成两数相加，然后再与100求和，由类B来负责。
public class Test6 {
public static void main(String[] args) {
B b = new B();
System.out.println("100-50=" + b.func1(100, 50));
System.out.println("100-80=" + b.func1(100, 80));
System.out.println("100+20+100=" + b.func2(100, 20));
}
static class A {
public int func1(int a, int b) {
return a - b;
}
}
static class B extends A {
public int func1(int a, int b) {
return a + b;
}
public int func2(int a, int b) {
return func1(a, b) + 100;
}
}
}
2.3.4、继承的风险分析和做法
- 发现原来运行正常的相减功能发生了错误。原因就是类B无意中重写了父类的方法，造成原有功能出现错误。
- 我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差。特别是运行多态比较频繁的时候.
- 如果非要重写父类的方法的做法:
- 原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖，聚合，组合等关系代替。
3、依赖倒转原则
3.1、定义
- 高层模块不应该依赖低层模块，二者都应该依赖其抽象
- 抽象不应该依赖细节，细节应该依赖抽象。
3.1.1、对3.1的具体说明
- 类A直接依赖类B，如果要将类A改为依赖类C，则必须通过修改类A的代码来达成。此时，类A一般是高层模块，负责复杂的业务逻辑，类B和类C是低层模块，负责基本的原子操作；修改A会给程序带来风险。
- 将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或类C发生联系，则会大大降低修改A给程序带来风险。
3.2、什么是依赖倒置原则
-
依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。
- 抽象指的是接口或抽象类
- 细节就是具体的实现类
- 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
-
依赖倒置的中心思想是面向接口编程
3.3、案例
public class Test6 {
public static void main(String[] args) {
Mother monther = new Mother();
monther.narrate(new Book());
}
static class Book {
public String getContent() {
return "很久很久以前。。。。。";
}
}
//母亲
static class Mother {
//讲故事
public void narrate(Book book) {
System.out.println(book.getContent());
}
}
}
如果读的对象是报纸，杂志，却发现客户端不适用了，我们引入一个抽象的接口IReader,代表读物。
public class Test8 {
public static void main(String[] args) {
Mother monther = new Mother();
monther.narrate(new Book());
monther.narrate(new Newspaper());
}
//读物
interface IReader {
String getContent();
}
static class Newspaper implements IReader {
public String getContent() {
return "切尔西豪取12连胜";
}
}
static class Book implements IReader {
public String getContent() {
return "很久很久以前。。。。";
}
}
//母亲
static class Mother {
//讲故事
public void narrate(IReader reader) {
System.out.println(reader.getContent());
}
}
}
3.4、优点
采用依赖倒置原则给多人并行开发带来极大的便利，比如上列中Mother类与Book类直接耦合，Mother必须等Book类编码完成后才可以进行编码，因为Mother类依赖于Book类。修改后的程序可以同时开工，互不影响。
3.5、实际编程中，一般需要做到如下3点
- 低层模块尽量都要有抽象类或接口，或者两者都有。
- 变量的声明类型尽量是抽象类或接口。
- 使用继承时遵循里氏替换原则
4、接口隔离原则
- 客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
- 类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类C来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
- 将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
4.1、举例说明接口隔离原则
4.1.1、图的意思:
- 类A依赖接口I中的方法1，方法2，方法3，类B是对类A依赖的实现；
- 类C依赖接口I中的方法1，方法4，方法5，类D是对类C依赖的实现。
- 对于类B和类D来说，虽然存在用不到的方法（红色标记所示），但由于实现了接口I，所以也必须要实现这些用不到的方法。
4.1.2 代码如下
public class Test8 {
public static void main(String[] args) {
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());
System.out.println("------------");
C c = new C();
c.depend1(new D());
c.depend2(new D());
c.depend3(new D());
}
interface I {
void method1();
void method2();
void method3();
void method4();
void method5();
}
static class A {
public void depend1(I i) {
i.method1();
}
public void depend2(I i) {
i.method2();
}
public void depend3(I i) {
i.method3();
}
}
static class C {
public void depend1(I i) {
i.method1();
}
public void depend2(I i) {
i.method4();
}
public void depend3(I i) {
i.method5();
}
}
static class B implements I {
public void method1() {
System.out.println("类B实现接口I的方法1");
}
public void method2() {
System.out.println("类B实现接口I的方法2");
}
public void method3() {
System.out.println("类B实现接口I的方法3");
}
public void method4() {
}
public void method5() {
}
}
static class D implements I {
public void method1() {
System.out.println("类D实现接口I的方法1");
}
public void method2() {
}
public void method3() {
}
public void method4() {
System.out.println("类D实现接口I的方法4");
}
public void method5() {
System.out.println("类D实现接口I的方法5");
}
}
}
可以看到，接口中出现的方法，不管对依赖于它的类有没有作用，实现类中都必须去实现这些方法。于是我们将原接口I拆分为三个接口
public class Test10 {
public static void main(String[] args) {
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());
System.out.println("-----------------");
C c = new C();
c.depend1(new D());
c.depend2(new D());
c.depend3(new D());
}
interface I1 {
void method1();
}
interface I2 {
void method2();
void method3();
}
interface I3 {
void method4();
void method5();
}
static class A {
public void depend1(I1 i) {
i.method1();
}
public void depend2(I2 i) {
i.method2();
}
public void depend3(I2 i) {
i.method3();
}
}
static class C {
public void depend1(I1 i) {
i.method1();
}
public void depend2(I3 i) {
i.method4();
}
public void depend3(I3 i) {
i.method5();
}
}
static class B implements I1, I2 {
public void method1() {
System.out.println("类B实现接口I1的方法1");
}
public void method2() {
System.out.println("类B实现接口I2的方法2");
}
public void method3() {
System.out.println("类B实现接口I2的方法3");
}
}
static class D implements I1, I3 {
public void method1() {
System.out.println("类D实现接口I的方法1");
}
public void method4() {
System.out.println("类D实现接口I的方法4");
}
public void method5() {
System.out.println("类D实现接口I的方法5");
}
}
}
说到这里，可能会觉得接口隔离原则和之前的单一职责原则很相似，其实不然。
- 单一职责注重职责，而接口隔离原则注重对接口依赖的隔离；
- 单一职责是约束类，其次是方法，针对的是程序中的实现和细节；而接口隔离原则约束的是接口，针对的是抽象，程序整体框架的构建。
5、迪米特法则
5.1、定义
- 也叫最少知道原则，即一个类对自己依赖的类知道的越少越好，或者说一个对象应该对其他对象保持最少的了解
- 对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息。
- 更简单的定义：只与直接的朋友通信。
- 直接的朋友
- 每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。
- 我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。
- 也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
- 耦合的方式：
- 依赖，关联，组合，聚合等。
本质：自己类的业务功能在自己类里面写，不要在其他类里面写。
5.2、举例说明：有一个集团公司，下属单位有分公司和直属部门，现要求打印出所有下属单位的员工ID。
public class Test11 {
public static void main(String[] args) {
CompanyManager e = new CompanyManager();
e.printAllEmployee(new SubCompanyManager());
}
//总公司员工
static class Employee {
public String id;
}
//子公司员工
static class SubEmployee {
public String id;
}
//子公司
static class SubCompanyManager {
public List<SubEmployee> getAllEmployee() {
List<SubEmployee> list = new ArrayList();
for (int i = 0; i < 3; i++) {
SubEmployee emp = new SubEmployee();
emp.id = "分公司" + i;
list.add(emp);
}
return list;
}
}
//总公司
static class CompanyManager {
public List<Employee> getAllEmployee() {
List<Employee> list = new ArrayList<>();
for (int i = 0; i < 5; i++) {
Employee emp = new Employee();
emp.id = "总公司" + i;
list.add(emp);
}
return list;
}
public void printAllEmployee(SubCompanyManager sub) {
List<SubEmployee> list1 = sub.getAllEmployee();
for (SubEmployee e : list1) {
System.out.println(e.id);
}
System.out.println("--------------");
List<Employee> list2 = this.getAllEmployee();
for (Employee e : list2) {
System.out.println(e.id);
}
}
}
}
这个设计的问题在于CompanyManager中，SubEmployee类并不是CompanyManager类的直接朋友，按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:
问题
public class Test12 {
public static void main(String[] args) {
CompanyManager e = new CompanyManager();
e.printAllEmployee(new SubCompanyManager());
}
//总公司员工
static class Employee {
public String id;
}
//子公司员工
static class SubEmployee {
public String id;
}
//子公司
static class SubCompanyManager {
public List<SubEmployee> getAllEmployee() {
List<SubEmployee> list = new ArrayList();
for (int i = 0; i < 3; i++) {
SubEmployee emp = new SubEmployee();
emp.id = "分公司" + i;
list.add(emp);
}
return list;
}
public void printEmployee() {
List<SubEmployee> list1 = this.getAllEmployee();
for (SubEmployee e : list1) {
System.out.println(e.id);
}
}
}
//总公司
static class CompanyManager {
public List<Employee> getAllEmployee() {
List<Employee> list = new ArrayList<>();
for (int i = 0; i < 5; i++) {
Employee emp = new Employee();
emp.id = "总公司" + i;
list.add(emp);
}
return list;
}
public void printAllEmployee(SubCompanyManager sub) {
sub.printEmployee();
System.out.println("--------------");
List<Employee> list2 = this.getAllEmployee();
for (Employee e : list2) {
System.out.println(e.id);
}
}
}
}
改动点
6、开闭原则
- 一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化的。
- 用抽象构建框架，用实现扩展细节。
- 当我们遵循前面介绍的5大原则，以及使用23中设计模式的目的就是遵循开闭原则。
6.1、软件实体
- 项目或软件产品中按照一定的逻辑规则划分的模块
- 抽象和类
- 方法
6.2、举例：以书店销售书籍为例，其类图如下
public class Test13 {
public static void main(String[] args) {
IBook novel = new NovelBook("笑傲江湖", 100D);
System.out.println("书籍名字：" + novel.getName() + ",价格：" + novel.getPrice());
}
//书籍
interface IBook {
String getName();
Double getPrice();
}
//小说类书籍
static class NovelBook implements IBook {
private String name;
private Double price;
public NovelBook(String name, Double price) {
this.name = name;
this.price = price;
}
public String getName() {
return this.name;
}
public Double getPrice() {
return price;
}
}
}
6.3、这时候产品经理过来了，需要对小说类书籍进行打折销售,我们要如何应对这样一个需求变化呢？
6.3.1、三种方法可以解决此问题
6.3.1.1、修改接口（error）
在IBook接口中，增加一个方法getOffPrice(),专门用于进行打折处理，所有的实现类实现此方法。但是这样的一个修改方式，实现类NovelBook要修改，同时IBook接口应该是稳定且可靠，不应该经常发生改变，否则接口作为契约的作用就失去了。因此，此方案否定。
6.3.1.2、修改实现类（error）
修改NovelBook类的方法，直接在getPrice()方法中实现打折处理。
此方法是有问题的，例如我们如果getPrice()方法中只需要读取书籍的打折前的价格呢？这不是有问题吗？当然我们也可以再增加getOffPrice()方法，这也是可以实现其需求，但是这就有二个读取价格的方法，因此，该方案也不是一个最优方案。
6.3.1.3、通过扩展实现变化
我们可以增加一个子类OffNovelBook,覆写getPrice方法。此方法修改少，对现有的代码没有影响，风险少，是个好办法。
public class Test13 {
public static void main(String[] args) {
IBook novel = new OffNovelBook("笑傲江湖", 100D);
System.out.println("书籍名字：" + novel.getName() + ",价格：" + novel.getPrice());
}
//书籍
interface IBook {
String getName();
Double getPrice();
}
//小说类书籍
static class NovelBook implements IBook {
private String name;
private Double price;
public NovelBook(String name, Double price) {
this.name = name;
this.price = price;
}
public String getName() {
return this.name;
}
public Double getPrice() {
return price;
}
}
static class OffNovelBook extends NovelBook {
public OffNovelBook(String name, Double price) {
super(name, price);
}
//覆写价格方法，当价格大于40，就打8析，其他价格就打9析
public Double getPrice() {
if (super.price > 40) {
return super.price * 0.8;
} else {
return super.price * 0.9;
}
}
}
}
6.4、为什么使用开闭原则
- 开闭原则非常有名，只要是面向对象编程，在开发时都会强调开闭原则
- 开闭原则是最基础的设计原则，其它的五个设计原则都是开闭原则的具体形态，依照java语言的称谓，开闭原则是抽象类，而其它的五个原则是具体的实现类。
- 开闭原则可以提高复用性
- 在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来，不是在一个类中独立实现一个业务逻辑。
- 缩小逻辑粒度，可以代码提高复用率。
- 开闭原则可以提高维护性
- 代码上线后，还可能要对程序进行扩展，维护人员最乐意的事是扩展一个类，而不是修改一个类。
6.5、如何使用开闭原则
- 抽象约束
- 通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放 。
- 通过接口或抽象类约束扩散，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法。
- 参数类型，引用对象尽量使用接口或抽象类，而不是实现类，这主要是实现里氏替换原则的一个要求。
- 抽象层尽量保持稳定，一旦确定就不要修改
- 通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放 。
- 配置参数控制行为
编程是一个很苦很累的活，那怎么才能减轻压力呢？答案是尽量使用配置参数来控制程序的行为，减少重复开发。 - 制定项目约定
- 对项目来说，约定优于配置。这比通过接口或抽象类进行约束效率更高，而扩展性一点也没有减少。
- 封装变化
- 将相同的变化封装到一个接口或抽象类中
- 将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。
扫一扫
6250
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
