1，设计模式
1.1 软件设计模式产生背景
1.2 软件设计模式概念
软件设计模式（Software Design Pattern），是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈的代码设计经验的总结，具有一定的普遍性，可以反复被使用的
1.3 学习设计模式的必要性
设计模式的本质是面向对象上街原则的实际运用，是对类的封装性、继承性、多态性以及类的关联关系和组合关系的充分理解。
正确使用设计模式优点：
- 提高思维能力、编程能力和设计能力
- 使得程序上街更加标准化、代码百年之更加工程化、使得软件开发效率大大提高，从而缩短软件的开发周期
- 使得设计的diamond可重用性高、可读性强、可靠性高、灵活性好、可维护性强。
1.4 设计模式分类
创建型模式
用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”，GoF书中提供了单例、原型、工厂方法、抽象工厂、建造者等5种创建型模式。
结构型模式
用于描述如何将类或对象按某种布局组成更大的结构，GoF书中提供了代理、适配器、桥接、装饰、外观、享元、组合等7种结构型模式。
行为性模式
用于描述类或对象之间怎样相互协作共同完成单个对象无法单独完成的任务，以及怎样分配职责。GoF书中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等11种行为型模式。
2，UML图
统一建模语言（Unified Modeling Language，UML）是用来设计软件的可视化建模语言。特点是简单、统一、图形化、能表达软件设计种的动态与静态信息。
2.1类图概述
类图（Class digram）是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性的信息，类图是面向对象建模的主要组成部分。
2.2类图的作用
- 在软件工程中，类图是一种惊天的结构图，描述了系统的类的集合，类的属性和类之间的关系，简化了人们对系统的理解。
- 类图是系统分析和设计阶段的重要产物，是系统编码和测hi是的额重要模型。
2.3类图表示法
2.3.1类的表示方法
在UML类图中，类使用半酣类名、属性（field）和方法(method)且带有分割线的矩形来表示，比如下图表示一个Employee类，它包含name，age和address这3个属性，以及work()方法
属性/方法名称前加的加号和减号表示了这个属性/方法的可见性，UML类图中表示可见性的符号有三种：
- +表示public
- -表示private
表示protected
属性的完整表示方法是：可见性 名称：类型 [ = 缺省值]
方法的完整表示方式是：可见性 名称（参数列表）[ : 返回类型]
注意：
1.括号中的内容表示可选
2.也有将类型放在变量名前面，返回值类型放在方法名前面
例子：
Demo定义了三个方法：
method()方法：修饰符为public，没有参数，没有返回值
method1()方法：修饰符为private，没有参数，返回值类型为String
method2()方法：修饰符为protexted，接收两个参数，第一个参数为int，第二个参数为String，返回值类型是int
2.3.2 类与类之间关系的表示方式
2.3.2.1关联关系
关联关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。关联关系是类与类直接按最常用的一种关系，非为一般关联关系、聚合关系和组合关系
关联又可以分为单向关联、双向该你了，自关联
1，单向关联
在UML类图中单向关联用一个带箭头的实线表示。上图表示每个顾客都有一个地址，这通过让Customer类持有一个类型为Address的成员变量类实现。
2，双向关联
所谓的双向关联就是双方各自持有对方类型的成员变量。
在UML类图中，双向关联用一个不带箭头的直线表示。上图中子啊Customer类中维护一个List，表示一个顾客可以购买多个商品；在Product类中维护一个Customer类型的成员变量表示这个产品被哪个顾客所购买。
3，自关联
自关联在UML类图中用一个带有箭头且指向自身的线表示。上图的意思就是Node类包含类型为Node的成员变量，也就是“自己包含自己”。
2.3.2.2 聚合关系
聚合关系是关联关系的一种，是强关联关系，是部分和整体之间的关系。
聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如：学校和老师的关系，学校包含老师，但是如果学校停办了，老师依然存在。
在UML类图中，聚合关系可以用带空心菱形的实现表示，菱形指向整体。下图是大学和教师的关系图：
2.3.2.3 组合关系
组合表示类之间的整体与部分的关系，但它是一种更加强烈的聚合关系。
在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。例如：头和嘴的关系，没有了头，嘴也就不存在了。
在UML类图中，组合关系用带实心菱形的实线来表示，菱形指向整体，下图所示是头和嘴的关系图：
2.3.2.4 依赖关系
依赖关系是一种使用关系，它是对象之间耦合程度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。
在UML类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。下图所示是司机和汽车的关系图，司机驾驶汽车：
2.3.2.5 继承关系
继承关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系。
在UML类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。在代码实现时，使用面向对象的继承机制来实现泛化关系。例如：Student类和Teacher类都是Person类的子类。
2.3.2.6 实现关系
实现关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中国的操作实现接口中所声明的所有的抽象操作。
在UML类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。例如：汽车和船实现了交通工具。
3，软件设计原则
在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据6条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。
3.1 开闭原则
对扩展开放，对修改关闭。在程序需要进行扩展的时候，不能去修改原有的代码，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。
想要达到这样的效果，我们就需要接口和抽象类。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生出来的实现类来进行扩展，当软件需要发生变化时，只需要根据要求重新派生一个实现类来扩展就可以了。
下面哦才能够搜狗输入法的皮肤为例介绍开闭原则的应用。
例子：搜狗输入法的皮肤设计
分析：搜狗输入法的皮肤时输入法背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的输入法的皮肤，也可以从网上下载新的皮肤。这些皮肤有共同的特点，可以为其定义一个抽象类（AbstractSkin），而每个具体的皮肤（DefaultSpecificSkin和HiSpecificSkin）是其子类。用户窗体可以根据需要选择或增加新的主题，而不需要修改原代码，所以它是满足开闭原则的。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| package com.cup.principles.demo1;
public abstract class AbstractSkin {
public abstract void display();
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| package com.cup.principles.demo1;
public class DefaultSkin extends AbstractSkin{
public void display() {
System.out.println("默认皮肤");
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| package com.cup.priciples.demo1;
public class HiSkin extends AbstractSkin {
public void display() {
System.out.printlin("Hi皮肤");
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| package com.cup.priciples.demo1;
public class SougouInput {
private AbstractSkin skin;
public void setSkin(AbstractSkin skin) {
this.skin = skin;
}
public void display() {
skin.display();
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| package com.cup.priciples.demo1;
public class Client {
public static void main(String[] args) {
SougouInput input = new SougouInput();
DefaultSkin skin = new DefaultSkin();
input.setSkin(skin);
input.display();
}
}
|
3.2 里氏代换原则
里氏代换原则是面向对象设计的而基本原则之一。
里氏代换原则：任何基类可以出现的地方，子类一定可以出现。通俗理解：子类可以扩展父类的功能，但不能该百年父类原有的功能。换句话说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用堕胎比较频繁时，出现运行出错的概率会非常大。
里氏代换原则经典例子
例子：正方形不是长方形。
在数学里面，正方形毫无疑问时长方形，他是一个长宽相等的长方形。所以，我们开发的一个于几何图像相关的软件系统，就可以顺理成章的让正方形继承长方形。
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
27
28
29
30
| package com.cup.principles.demo2.before;
public class Rectangle {
private double length;
private double width;
public double getLength() {
return length;
}
public void setLength(double length) {
this.length = length;
}
public double getWidth() {
return width;
}
public void setWidth(double width) {
this.width = width;
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| package com.principles.demo2.before;
public class Square extends Rectangle {
@Override
public void setLength(double length) {
super.setLength(length);
super.setWidth(length);
}
@Override
public void setWidth(double width) {
super.setLength(width);
super.setWidth(width);
}
}
|
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
27
28
29
30
31
32
33
34
35
36
37
| package com.cup.principles.demo2.before;
public class RectangleDemo {
public static void main(String[] args) {
Rectangle r = new Rectangle();
r.setWidth(20);
r.setWidth(10);
resize(r);
printLengthAngWidth(r);
}
public static void resize(Rectangle rectangle) {
while(rectangle.getWidth() <= rectangle.getLength()) {
rectang;e.setWidth(rectangle.getWidth() + 1);
}
}
public static void printLengthAngWidth (Rectangle rectangle) {
System.out.println(rectangle.getWidth());
System.out.println(rectangle.getLength());
}
}
|
如果进行下面的操作
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| package com.cup.principles.demo2.before;
public class RectangleDemo {
public static void main(String[] args) {
Rectangle r = new Rectangle();
r.setWidth(20);
r.setWidth(10);
resize(r);
printLengthAngWidth(r);
System.out.prinln("===================");
Square s = new Square();
s.setLenth(10);
resize(s);
printLengthAngWidth(s);
}
public static void resize(Rectangle rectangle) {
while(rectangle.getWidth() <= rectangle.getLength()) {
rectang;e.setWidth(rectangle.getWidth() + 1);
}
}
public static void printLengthAngWidth (Rectangle rectangle) {
System.out.println(rectangle.getWidth());
System.out.println(rectangle.getLength());
}
}
|
卡死了，程序继续在运行
我们运行一下这段代码就会发现，加入我们把一个普通长方形作为参数传入resize方法，就会看到长方形阔度逐渐增长的效果，当宽度大于长度，代码就会停止，这种行为的结果符合我们的预期；假如我们再把一个正方形作为参数传入resize方法后，就会看到正方形的宽度和长度不断增长，代码会一致运行下去，直至系统产生溢出错误。所以，普通的长方形是适合这段代码的，正方形不适合。
我们得出结论：在resize方法中，Rectangle类型的参数是不能被Square类型的参数是不能被Square类型的参数所替代，如果进行了替换就得不到预期结果。因此，Square类和Rectangle类之间的继承关系违反了里氏代换原则，它们之间的继承关系不成立，正方形不是长方形。
如何改进呢？此时我们需要重新设计他们之间的关系，抽象出来一个四边形接口（Quardrilateral），让Rectangle类和Square类实现Quadrilateral接口
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| package com.cup.principles.demo2.after;
public interface Quardrilateral {
double getLength();
double getWidth();
}
|
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
27
28
29
| package com.cup.principles.demo2.after;
public class Square implements Quadrilateral {
private double side;
public double getSide() {
return side;
}
public void setSide(double side) {
this.side = side;
}
public double getLength() {
return side;
}
public double getWidth() {
return side;
}
}
|
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
27
28
29
30
| package com.cup.principles.demo2.after;
public class Rectangle implements Quadrilateral {
private double length;
private double width;
public double setLength(double length) {
this.length = length;
}
public void setWidth(double width) {
this.width = width;
}
public double getLength() {
return length;
}
public double getWidth() {
return width;
}
}
|
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
27
28
29
30
31
32
33
34
| package com.cup.pinciples.demo2.after;
public class RectangleDemo {
public static void main(Sting[] args) {
Rectangle r = new Rectangle();
r.setLength(20);
r.setWidth(10);
resise(r);
printLengthAndWidth(r);
}
public static void resize(Rectangle rectangle) {
while(rectangle.getWidth() <= rectangle.getLength()) {
rectang;e.setWidth(rectangle.getWidth() + 1);
}
public static void printLengthAndWidth(Quadrilateral quadrilateral) {
System.out.println(quadrilateral.getLength());
System.out.println(quadrilateral.getWidth());
}
}
|
3.3依赖倒转原则
高层模块不应该依赖于底层模块，两者都应该依赖其抽象；抽象不应该依赖于细节，细节应该依赖于抽象。简单说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与是西安模块间的耦合。
下面看一个例子来理解依赖倒转原则
【例】组装电脑
现在要组装一台电脑，需要配件CPU，硬盘，内存条。只有这些配置都有了，计算机才能正常的与性能。选择CPU有很多选择，如Inter，AMD等，硬盘可以选择希捷，西部数据等，内存条可以选择金士顿，海盗船等。
类图如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| package com.cup.principles.demo3.before;
public class XiJieHardDisk {
public void save(String data) {
System.out.printlin("使用希捷硬盘存储数据为" + data);
}
public String get() {
System.out.println("使用希捷硬盘获取数据为");
return "数据";
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| package com.cup.principles.demo3.before;
public class IntelCpu {
public void run() {
System.out.println("使用Intel处理器");
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| package com.cup.principles.demo3.before;
public class KingstonMemory {
public void save() {
System.out.println("使用金士顿内存条");
}
}
|
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
| package com.cup.principles.demo3.before;
public class Computer {
private XiJieHardDisk hardDisk;
private IntelCpu cpu;
private KingstonMemory memory;
public XiJieHardDisk getHardDisk() {
return hardDisk;
}
public void setHardDisk(XiJieHardDisk hardDisk) {
this.hardDisk = hardDisk;
}
public IntelCpu getCpu() {
retrun cpu;
}
public void setCpu(IntelCpu cpu) {
this.cpu = cpu;
}
public KingstonMemory getMemory() {
return memory;
}
public void setMemory(KingstonMemory memory) {
this.memory = memory;
}
public void run() {
System.out.println("开始运行计算机");
String data = hardDisk.get();
System.out.println("从硬盘上获取的数据是：" + data);
cpu.run();
memory.save();
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| package com.cpu.principles.demo3.before;
public class ComputerDemo {
public static void main(String[] args) {
XiJieHardDisk hardDisk = new XiJieHardDisk();
IntelCpu cpu = new IntelCpu();
KingstonMemory memory = new KingstonMemory();
Computer c = new Computer();
c.setCpu(cpu);
c.setHardDisk(hardDisk);
c.setMemory(memory);
c.run();
}
}
|
上面代码可以看到已经组装了一台电脑，但是似乎组装的电脑的cpu只能是Intel，内存条只能是金士顿的，硬盘只能是希捷的，这对用户肯定是不友好的额，用户有了机箱后肯定是按照自己的喜好，选择自己喜欢的额配件。
根据依赖倒转原则进行改进
代码我们只需要修改Computer类，让Computer类依赖抽象（各个配件的接口），而不是依赖于各个组件具体的实现类。
类图如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| package com.cup.principles.demo3.after;
public interface HardDisk {
public void save(String data);
public String get();
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| package com.cuo.principes.demo3.after;
public class XiJieHardDisk implements HardDisk {
public void save(String data) {
System.out.printlin("使用希捷硬盘存储数据为" + data);
}
public String get() {
System.out.println("使用希捷硬盘获取数据为");
return "数据";
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| package com.cup.principles.demo3.after;
public interface Cpu {
public void run();
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| package com.cup.principles.demo3.before;
public class IntelCpu implements Cpu{
public void run() {
System.out.println("使用Intel处理器");
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| package com.cup.principles.demo3.after;
public interface Memory {
public void save();
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| package com.cup.principles.demo3.before;
public class KingstonMemory implements Memory{
public void save() {
System.out.println("使用金士顿内存条");
}
}
|
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
| package com.cup.principles.demo3.before;
public class Computer {
private HardDisk hardDisk;
private Cpu cpu;
private Memory memory;
public HardDisk getHardDisk() {
return hardDisk;
}
public void setHardDisk(HardDisk hardDisk) {
this.hardDisk = hardDisk;
}
public Cpu getCpu() {
retrun cpu;
}
public void setCpu(Cpu cpu) {
this.cpu = cpu;
}
public Memory getMemory() {
return memory;
}
public void setMemory(Memory memory) {
this.memory = memory;
}
public void run() {
System.out.println("开始运行计算机");
String data = hardDisk.get();
System.out.println("从硬盘上获取的数据是：" + data);
cpu.run();
memory.save();
}
}
|
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
27
| package com.cpu.principles.demo3.before;
public class ComputerDemo {
public static void main(String[] args) {
HardDisk hardDisk = new XiJieHardDisk();
Cpu cpu = new IntelCpu();
Memory memory = new KingstonMemory();
Computer c = new Computer();
c.setCpu(cpu);
c.setHardDisk(hardDisk);
c.setMemory(memory);
c.run();
}
}
|
3.4 接口隔离原则
客户端不应该被迫依赖于它不使用的方法；一个类对另一个类的依赖应该建立在最小的接口上。
下面看一个例子来理解接口隔离原则
【例】安全门案例
我们需要创建一个Hi品牌的安全门，该安全门具有防火、防水、防盗的功能，可以将防火，防水，防盗功能提取成一个接口，形成一套规范。类图如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| package com.cup.principles.demo4.before;
public interface SafetyDoor {
void antiTheft();
void fireProof();
void waterProof();
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| package com.cup.principles.demo4.before;
public class CupkSafetyDoor implements SafetyDoor {
public void antiTheft() {
System.out.println("防盗");
}
public void fireProof() {
System.out.println("防火");
}
public void waterTheft() {
System.out.println("防水");
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| package com.cup.principles.demo4.before;
public class Client {
public static void main(String[] args) {
CupkSafetyDoor door = new CupkSafetyDoor();
door.antiTheft();
door.fireProof();
door.waterProof();
}
}
|
上面的设计我们发现了它存在的问题，黑马品牌的安全门具有防盗、防水、防火的功能。现在如果我们还需要再创建一个cupk品牌的安全门，而该安全门只具有防盗、防水功能呢？很显然如果是实现SafetyDoor接口就违背了接口隔离原则，那么我们如何进行修改呢？看下面类图：
1
2
3
4
5
6
7
8
9
10
11
12
| package com.cup.principles.demo4.after;
public interface AntiTheft {
void antiTheft();
}
|
1
2
3
4
5
6
7
8
9
10
11
12
| package com.cup.principles.demo4.after;
public interface FireProof {
void fireProof();
}
|
1
2
3
4
5
6
7
8
9
10
11
12
| package com.cup.principles.demo4.after;
public interface WaterProof {
void waterProof();
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| package com.cup.principles.demo4.after;
public class CupkSafetyDoor implements AntiTheft, FireProof, WaterProof {
public void antiTheft() {
System.out.println("防盗");
}
public void fireProof() {
System.out.println("防火");
}
public void waterProof() {
System.out.println("防水");
}
}
|
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
| package com.cup.principles.demo4.after;
public class Client {
public static void main(String[] args) {
CupkSafetyDoor door = new CupkSafetyDoor();
door.antiTheft();
door.fireProof();
door.waterProof();
System.out.println("==========");
CupkerSafetyDoor door1 = new CupkerSafetyDoor();
door1.antiTheft();
door1.fireProof();
}
}
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| package com.cup.principles.demo4.after;
public class CupkerSafetyDoor implements AntiTheft, FireProof {
public void antiTheft() {
System.out.println("防盗");
}
public void fireProof() {
System.out.println("防火");
}
}
|
3.5 迪米特法则
迪米特法则又叫最少知识原则。
只和你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。
其含义是：如果两个软件实体无需直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。
下面看一个例子来理解接口隔离原则
【例】明星与经纪人的关系实例
明星由于全身心投入艺术，所以许多日常事务由经纪人来负责处理，如和粉丝的见面会，和媒体公司的业务洽谈等。这里的经纪人是明星的朋友，而粉丝和米欸天公司是陌生人，所以适合使用迪米特法则。
类图如下：