利用抽象数据类型将数据和基于数据的操作封装在一起,使其构成一个不可分割的独立实体。数据被保护在抽象数据类型的内部,尽可能地隐藏内部的细节,只保留一些对外的接口使其与外部发生联系。用户无需关心对象内部的细节,但可以通过对象对外提供的接口来访问该对象。
优点:
- 减少耦合:可以独立地开发、测试、优化、使用、理解和修改;
- 减轻维护的负担:可以更容易被理解,并且在调试的时候可以不影响其他模块;
- 有效地调节性能:可以通过剖析来确定哪些模块影响了系统的性能;
- 提高软件的可重用性;
- 降低了构建大型系统的风险:即使整个系统不可用,但是这些独立的模块却有可能是可用的。
Java 用访问修饰符实现封装:属性通常声明为 private,对外的方法声明为 public,四种访问权限的范围见访问权限。
以下 Person 类封装 name、gender、age 等属性,外界只能通过 get() 方法获取一个 Person 对象的 name 属性和 gender 属性,而无法获取 age 属性,但是 age 属性可以供 work() 方法使用。
注意到 gender 属性使用 int 数据类型进行存储,封装使得用户注意不到这种实现细节。并且在需要修改 gender 属性使用的数据类型时,也可以在不影响客户端代码的情况下进行。
public class Person {
private String name;
private int gender;
private int age;
public String getName() {
return name;
}
public String getGender() {
return gender == 0 ? "man" : "woman";
}
public void work() {
if (18 <= age && age <= 50) {
System.out.println(name + " is working very hard!");
} else {
System.out.println(name + " can't work any more!");
}
}
}继承实现了 IS-A 关系,例如 Cat 和 Animal 就是一种 IS-A 关系,因此 Cat 可以继承自 Animal,从而获得 Animal 非 private 的属性和方法(Cat 与 Animal 不在同一个包时,也不包括没有访问修饰符的成员)。
继承应该遵循里氏替换原则,子类对象必须能够替换掉所有父类对象。
Cat 可以当做 Animal 来使用,也就是说可以使用 Animal 引用 Cat 对象。父类引用指向子类对象称为向上转型。
Animal animal = new Cat();多态分为编译时多态和运行时多态:
- 编译时多态主要指方法的重载;
- 运行时多态指程序中定义的对象引用所指向的具体类型在运行期间才确定。
运行时多态有三个条件:
- 继承或实现接口;
- 覆盖(重写);
- 向上转型(父类或接口类型的引用指向子类对象)。
下面的代码中,乐器类(Instrument)有两个子类:Wind 和 Percussion,它们都覆盖了父类的 play() 方法,并且在 main() 方法中使用父类 Instrument 来引用 Wind 和 Percussion 对象。在 Instrument 引用调用 play() 方法时,会执行实际引用对象所在类的 play() 方法,而不是 Instrument 类的方法。
public class Instrument {
public void play() {
System.out.println("Instrument is playing...");
}
}public class Wind extends Instrument {
public void play() {
System.out.println("Wind is playing...");
}
}public class Percussion extends Instrument {
public void play() {
System.out.println("Percussion is playing...");
}
}public class Music {
public static void main(String[] args) {
List<Instrument> instruments = new ArrayList<>();
instruments.add(new Wind());
instruments.add(new Percussion());
for(Instrument instrument : instruments) {
instrument.play();
}
}
}Wind is playing...
Percussion is playing...
新增一种乐器只需要再写一个 Instrument 的子类,遍历和调用 play() 的循环不用修改。
编译器并不知道 instrument 实际指向哪个类,循环中的 instrument.play() 被编译成一条 invokevirtual 指令,参数是符号引用 Instrument.play:()V(javap 输出,见附录 A1)。运行时 JVM 才根据对象的实际类型选择方法:从对象所属的类开始,沿继承链向上找第一个签名相同的方法(JVM 规范 invokevirtual 一节)。这个过程称为动态分派。
每次调用都沿继承链查找太慢,HotSpot 为每个类维护一张虚方法表(vtable),按固定的槽位存放可被覆盖的方法的入口:子类的表先复制父类的表,覆盖了的方法替换对应槽位的入口,新增的方法追加在后面。play() 在 Instrument、Wind、Percussion 三张表中是同一个槽位,分别指向三个类自己的实现,调用时按槽位取出入口即可。通过接口调用的方法使用 invokeinterface,HotSpot 为它另外维护接口方法表(itable)。
重载则在编译时就确定了:编译器根据参数的静态类型选择重载的版本,写进字节码的符号引用中,称为静态分派。例如:
static void show(Instrument i) { System.out.println("show(Instrument)"); }
static void show(Wind w) { System.out.println("show(Wind)"); }
Instrument i = new Wind();
show(i); // show(Instrument)
show((Wind) i); // show(Wind)i 实际指向 Wind 对象,但它的静态类型是 Instrument,第一次调用编译成 show:(LInstrument;)V,运行时不会再改变。
不能被覆盖的方法只有一个实现,调用目标在编译时就能确定:静态方法用 invokestatic,构造方法用 invokespecial;private 和 final 方法虽然也用 invokevirtual 调用(JDK 21 javac 的输出),JVM 同样能直接确定调用目标。
需要注意的是,构造方法中调用可被覆盖的方法也会动态分派。new Guitar() 时,对象在执行构造方法之前就已分配好,实际类型已经是 Guitar;父类构造方法中的 play() 因此调用 Guitar 的版本,而这时子类的字段还没有初始化(字段的初始化在 super() 返回后才执行):
class Instrument {
Instrument() {
play();
}
public void play() {
System.out.println("Instrument is playing...");
}
}
class Guitar extends Instrument {
private String strings = "6 strings";
public void play() {
System.out.println("Guitar with " + strings);
}
}Guitar with null
输出中 strings 是默认值 null(JDK 21 实测,见附录 A2)。C++ 的规则不同,构造基类期间对象被视为基类,调用的是基类的版本。因此构造方法中不应直接或间接调用当前对象可被覆盖的方法。
每张类图后附有对应的 PlantUML 代码,更多语法见 PlantUML 官网。
用来描述继承关系,在 Java 中使用 extends 关键字。
@startuml
title Generalization
class Vehicle
class Car
class Truck
Vehicle <|-- Car
Vehicle <|-- Truck
@enduml
用来实现一个接口,在 Java 中使用 implements 关键字。
@startuml
title Realization
interface MoveBehavior
class Fly
class Run
MoveBehavior <|.. Fly
MoveBehavior <|.. Run
@enduml
表示整体由部分组成,但是整体和部分不是强依赖的,整体不存在了部分还是会存在。
@startuml
title Aggregation
class Computer
class Keyboard
class Mouse
class Screen
Computer o-- Keyboard
Computer o-- Mouse
Computer o-- Screen
@enduml
和聚合不同,组合中整体和部分是强依赖的,整体不存在了部分也不存在了。比如公司和部门,公司没了部门就不存在了。但是公司和员工就属于聚合关系了,因为公司没了员工还在。
@startuml
title Composition
class Company
class DepartmentA
class DepartmentB
Company *-- DepartmentA
Company *-- DepartmentB
@enduml
表示不同类对象之间有结构上的联系,通常体现为一个类把另一个类作为成员长期持有。关联可以用 1 对 1、多对 1、多对多来表示数量关系。比如学生和学校就是一种关联关系,一个学校可以有很多学生,但是一个学生只属于一个学校,因此这是一种多对一的关系。
@startuml
title Association
class School
class Student
School "1" - "*" Student
@enduml
依赖表示 A 类用到了 B 类,B 类变化时 A 类可能也要修改。类图中单独画依赖时,通常是下面三种临时的使用;A 类把 B 类作为成员变量长期持有时,画成关联关系:
- B 类是 A 类方法中的局部变量;
- B 类是 A 类方法的参数;
- A 类调用 B 类的静态方法。
@startuml
title Dependency
class Vehicle {
move(MoveBehavior)
}
interface MoveBehavior {
move()
}
note "MoveBehavior.move()" as N
Vehicle ..> MoveBehavior
Vehicle .. N
@enduml
| 简写 | 全拼 | 中文翻译 |
|---|---|---|
| SRP | The Single Responsibility Principle | 单一责任原则 |
| OCP | The Open Closed Principle | 开放封闭原则 |
| LSP | The Liskov Substitution Principle | 里氏替换原则 |
| ISP | The Interface Segregation Principle | 接口分离原则 |
| DIP | The Dependency Inversion Principle | 依赖倒置原则 |
修改一个类的原因应该只有一个。
换句话说就是让一个类只负责一件事,当这个类需要做过多事情的时候,就需要分解这个类。
如果一个类承担的职责过多,就等于把这些职责耦合在了一起,一个职责的变化可能会削弱这个类完成其它职责的能力。
类应该对扩展开放,对修改关闭。
扩展就是添加新功能的意思,因此该原则要求在添加新功能时通过新增代码实现,不需要修改已有的代码。
符合开闭原则最典型的设计模式是装饰者模式,它可以动态地将责任附加到对象上,而不用去修改类的代码。
子类对象必须能够替换掉所有父类对象。
继承是一种 IS-A 关系,子类需要能够当成父类来使用,并且需要比父类更特殊。
如果不满足这个原则,那么各个子类的行为上就会有很大差异,增加继承体系的复杂度。
不应该强迫客户依赖于它们不用的方法。
因此使用多个专门的接口比使用单一的总接口要好。
高层模块不应该依赖于低层模块,二者都应该依赖于抽象;
抽象不应该依赖于细节,细节应该依赖于抽象。
高层模块包含一个应用程序中重要的策略选择和业务模块,如果高层模块依赖于低层模块,那么低层模块的改动就会直接影响到高层模块,从而迫使高层模块也需要改动。
依赖于抽象可以落实为下面几条启发式规则。它们不是绝对的,例如 String 这类稳定、不会变化的具体类可以直接依赖,创建和组装对象的代码也总要用到具体类:
- 任何变量都不应该持有一个指向具体类的指针或者引用;
- 任何类都不应该从具体类派生;
- 任何方法都不应该覆写它的任何基类中的已经实现的方法。
除了上述的经典原则,在实际开发中还有下面这些常见的设计原则。
| 简写 | 全拼 | 中文翻译 |
|---|---|---|
| LOD | The Law of Demeter | 迪米特法则 |
| CRP | The Composite Reuse Principle | 合成复用原则 |
| CCP | The Common Closure Principle | 共同封闭原则 |
| SAP | The Stable Abstractions Principle | 稳定抽象原则 |
| SDP | The Stable Dependencies Principle | 稳定依赖原则 |
迪米特法则又叫作最少知识原则(Least Knowledge Principle,简写 LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
尽量使用对象组合,而不是通过继承来达到复用的目的。
一起修改的类,应该组合在一起(同一个包里)。如果必须修改应用程序里的代码,希望所有的修改都发生在一个包里(修改关闭),而不是遍布在很多包里。
最稳定的包应该是最抽象的包,不稳定的包应该是具体的包,即包的抽象程度跟它的稳定性成正比。
包之间的依赖关系都应该是稳定方向依赖的,包要依赖的包要比自己更具有稳定性。
环境:JDK 21.0.13。在正文 Music 类的基础上加入两个重载的 show() 方法、一个 private 方法和一个 final 方法,运行后用 javap -c 查看 main() 中的调用指令(省略了 println 等无关的行):
Instrument i = new Wind();
show(i);
show((Wind) i);
Music m = new Music();
m.secret(); // private void secret()
m.fixed(); // public final void fixed()Wind is playing...
Percussion is playing...
show(Instrument)
show(Wind)
63: invokevirtual #54 // Method Instrument.play:()V
73: invokespecial #28 // Method Wind."<init>":()V
78: invokestatic #57 // Method show:(LInstrument;)V
85: invokestatic #63 // Method show:(LWind;)V
92: invokespecial #66 // Method "<init>":()V
97: invokevirtual #67 // Method secret:()V
101: invokevirtual #70 // Method fixed:()V
环境:JDK 21.0.13。正文 Instrument、Guitar 两个类加上 main() 中的 new Guitar(),运行输出和 javap -c Instrument 中构造方法的字节码:
Guitar with null
Instrument();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: invokevirtual #7 // Method play:()V
8: return
- Eckel B. Java 编程思想 [M]. 机械工业出版社, 2002.
- The Java Virtual Machine Specification, Java SE 21 Edition:invokevirtual
- 周志明. 深入理解 Java 虚拟机:第 3 版 [M]. 机械工业出版社, 2019. 第 8 章“方法调用”。
- Martin R C. 敏捷软件开发:原则、模式与实践 [M]. 清华大学出版社, 2003.
- 面向对象设计的 SOLID 原则
- 看懂 UML 类图和时序图
- UML 系列——时序图(顺序图)sequence diagram
- 面向对象编程三大特性 ------ 封装、继承、多态






