在学习设计模式之前,需要了解一下面向对象的六大原则,设计模式大多都遵循这些原则,写代码时心中时刻不要忘记六大原则,利用它们能写出更整洁、低耦合、高内聚的代码,更加清晰的逻辑

该文章由网上以及书籍上的资料整理而来 :)

六大原则

单一职责原则


Single Responsibility Principle,简称SRP,对一个类而言,应该仅有一个引起它变化的原因,即一个类只负责一项职责

问题描述

当类 C 负责两个不同的职责:职责 M1,职责 M2,职责 M1 需求发生改变需要改变类 C 的时候,很有可能影响到原先的职责 M2 的功能

解决方案

一个类只负责一个职责,当需求改变时,不会影响到其他职责

里氏替换原则


Liskov Substitution Principle,简称LSP,所有引用基类的地方必须能透明地使用其子类的对象

问题描述

有一个功能 M,由类 C 完成,由于业务需要,需要拓展 M 功能 M1,此时需要由类 C 的子类 C1 完成拓展功能,当 C1 完成 M1 功能的同时,有可能导致原来 M 功能不可用

解决方案

当使用继承时,遵循里氏替换原则。类 M1 继承类 M 时,除添加新的方法完成 M1 的新增功能外,尽量不要重写父类 C 的方法,也尽量不要重载父类 C 的方法

继承作为面向对象三大特性之一,在给程序设计带来巨大便利的同时,也带来了弊端。比如使用继承会给程序带来侵入性,程序的可移植性降低,增加了对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能会产生故障

依赖倒置原则


Dependence Inversion Principle,简称DIP

  • 高层模块不应该依赖低层模块,高层模块是调用类,低层模块是实现类
  • 二者都应该依赖其抽象,抽象指接口或抽象类
  • 细节应该依赖抽象,细节指实现类

问题描述

有 B 和 C 两个实现类,类 A 直接依赖类 B,这种场景下,类 A 一般为高层模块,负责复杂业务逻辑,类 B 和类 C 是低层模块,负责原子操作,如果需要把类 A 改为依赖类 C,必须通过修改类 A 源代码,可能会引入不必要的风险

Tip:

  • 原子操作:不可分割的,在执行完毕之前不会被任何其它任务或事件中断的操作

解决方案

将类 A 修改为依赖接口 I ,类 B 和类 C 各自实现接口 I ,类 A 通过接口 I 间接与类 B 或者类 C 发生联系,则会大大降低修改类A的几率

示例代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
interface Animal{
public String getFood();
}

class Cat implements Animal {

@Override
public String getFood() {
return "鱼";
}
}

class Dog implements Animal{

@Override
public String getFood() {
return "骨头";
}
}

class Master {
// 依赖Animal接口
public void feed(Animal animal) {
String food = animal.getFood();
}
}

接口隔离原则


Interface Segregation Principle,简称ISP,一个类对另一个类的依赖应该建立在最小的接口上

问题描述

类 A 通过接口 I 依赖类 B,类 C 通过接口 I 依赖类 D,如果接口 I 对于类 A 和类 B 来说不是最小接口,则类 B 和类 D 必须去实现他们不需要的方法

解决方案

将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则

迪米特法则


Law of Demeter,简称LoD,也称为最少知识原则(Principle of Least Knowledge)或得墨忒耳定律,一个对象应该对其他对象保持最少的了解

问题描述

类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大

解决方案

尽量降低类与类之间的耦合

开闭原则


Open Close Principle,简称OCP,对象应该对扩展开放,对修改关闭,开闭原则是面向对象设计中最基础的设计原则

问题描述

在软件的开发工程中,因为需求变化,升级,重构和维护等原因,需要修改源代码,这样很有可能引入错误

解决方案

当软件有变化时,尽量通过扩展的行为实现变化,而不是通过修改已有的代码实现变化