# 结构型模式

结构型模式描述如何将类或对象按某种布局组成更大的机构。它分为类结构型模式和对象结构性模式,前者采用继承机制来组织接口和类,后者采用组合或聚合来组合对象

由于组合关系或聚合关系比继承关系耦合度低,满足 “合成服用原则”, 所以对象结构性模式壁垒结构型模式具有更大的灵活性

结构型模式分为以下 7 种 :

  • 代理模式
  • 适配器模式
  • 装饰者模式
  • 桥接模式
  • 外观模式
  • 组合模式
  • 享元模式

# 代理模式

由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这是,访问对象不适合或者不能直接引用目标对象,代理对象作为访问对象和目标对象之间的中介

Java 中的代理按照代理类生成时机不同又分为静态代理和动态代理。静态代理类在编译器就生成,而动态代理类则是在 Java 运行时动态生成。动态代理又有 JDK 代理和 CGLib 代理两种

代理模式分为三种角色 :

  • 抽象主题 (Subject) 类:通过接口或抽象类声明真实主题和代理对象实现的业务方法
  • 真实主题 (Real Subject) 类:实现了抽象主题中的具体业务,是代理对象所代表的真实对象,是最重要引用的对象
  • 代理 (Proxy) 类:提供了与真实主题相同的接口,其内部含有对真实主题的引用,它可以访问,控制或扩展真实主题的功能

# 静态代理

例:火车站卖票

如果要买火车票的话,需要去火车站买票,坐车到火车站,排队等一系列的操作,显然比较麻烦。而火车站在多个地方都有代售点,我们去代售点买票就方便很多了。这个例子其实就是典型的代理模式,火车站是目标对象,代售点是代理对象

image-20221121223356264

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
public class ProxyStation implements SellTickets{

private TrainStation trainStation = new TrainStation();
@Override
public void sell() {
System.out.println("在代售点卖票");
trainStation.sell();
System.out.println("代售点卖好了");
}
}

public class TrainStation implements SellTickets {
@Override
public void sell() {
System.out.println("火车站卖票");
}
}


public interface SellTickets {
void sell();
}


public class Client {
public static void main(String[] args) {
ProxyStation proxyStation = new ProxyStation();
proxyStation.sell();
}
}

# JDK 动态代理

Java 中提供了一个动态代理类 Proxy, Proxy 并不是我们上述所说的代理对象的类,而是提供了一个创建代理对象的静态方法 (newProxyInstance 方法) 来获取对象

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
public class ProxyFactory {
private TrainStation trainStation = new TrainStation();

public SellTickets getProxyObject() {
SellTickets obj = (SellTickets) Proxy.newProxyInstance(
trainStation.getClass().getClassLoader(),
trainStation.getClass().getInterfaces(),
(proxy, method, args) -> {
System.out.println("在代售点卖票");
Object invoke = method.invoke(trainStation);
System.out.println("卖好了");
return invoke;
}
);
return obj;
}
}


public class Client {
public static void main(String[] args) {
ProxyFactory proxyFactory = new ProxyFactory();
SellTickets proxyObject = proxyFactory.getProxyObject();
proxyObject.sell();
}
}
  • ProxyFactory 不是代理模式种所说的代理类,而是一个工厂类,来获取我们所需要的代理类。代理类是程序在运行过程中动态的在内存中生成的类.

以下是在内存中的动态代理类的信息

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
package com.wong.proxy.jdk_proxy;

import com.wong.proxy.staticstate.SellTickets;

import java.lang.invoke.MethodHandles;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.lang.reflect.UndeclaredThrowableException;

public final class $Proxy0
extends Proxy
implements SellTickets {
private static final Method m0;
private static final Method m1;
private static final Method m2;
private static final Method m3;

public $Proxy0(InvocationHandler invocationHandler) {
super(invocationHandler);
}

static {
try {
m0 = Class.forName("java.lang.Object").getMethod("hashCode", new Class[0]);
m1 = Class.forName("java.lang.Object").getMethod("equals", Class.forName("java.lang.Object"));
m2 = Class.forName("java.lang.Object").getMethod("toString", new Class[0]);
m3 = Class.forName("com.wong.proxy.staticstate.SellTickets").getMethod("sell", new Class[0]);
return;
} catch (NoSuchMethodException noSuchMethodException) {
throw new NoSuchMethodError(noSuchMethodException.getMessage());
} catch (ClassNotFoundException classNotFoundException) {
throw new NoClassDefFoundError(classNotFoundException.getMessage());
}
}

public final boolean equals(Object object) {
try {
return (Boolean) this.h.invoke(this, m1, new Object[]{object});
} catch (Error | RuntimeException throwable) {
throw throwable;
} catch (Throwable throwable) {
throw new UndeclaredThrowableException(throwable);
}
}

public final String toString() {
try {
return (String) this.h.invoke(this, m2, null);
} catch (Error | RuntimeException throwable) {
throw throwable;
} catch (Throwable throwable) {
throw new UndeclaredThrowableException(throwable);
}
}

public final int hashCode() {
try {
return (Integer) this.h.invoke(this, m0, null);
} catch (Error | RuntimeException throwable) {
throw throwable;
} catch (Throwable throwable) {
throw new UndeclaredThrowableException(throwable);
}
}

private static MethodHandles.Lookup proxyClassLookup(MethodHandles.Lookup lookup) throws IllegalAccessException {
if (lookup.lookupClass() == Proxy.class && lookup.hasFullPrivilegeAccess()) {
return MethodHandles.lookup();
}
throw new IllegalAccessException(lookup.toString());
}

public final void sell() {
try {
this.h.invoke(this, m3, null);
return;
} catch (Error | RuntimeException throwable) {
throw throwable;
} catch (Throwable throwable) {
throw new UndeclaredThrowableException(throwable);
}
}
}

从上面的类中,可以看出 :

  • 代理类 ($Proxy0) 实现了 SellTickets
  • 代理类 ($Proxy0) 将我们提供了的匿名内部类对象传递给了父类

# CGLib 动态代理

如果没有定义 SellTickets 接口,只定义了 TrainStation. 很显然 JDK 代理是无法使用了,因为 JDK 动态代理继承了 Proxy 类,而 Java 是单继承,所以要想获取被代理类信息,只能通过接口.

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
public class ProxyFactory implements MethodInterceptor {
public TrainStation getProxyObject() {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(TrainStation.class);
enhancer.setCallback(this);
return (TrainStation) enhancer.create();
}

@Override
public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
System.out.println("在代售点卖票");
Object o1 = methodProxy.invokeSuper(o, null);
TrainStation oo = (TrainStation) o;
System.out.println("卖好了");
System.out.println("o的class" + o.getClass());
System.out.println("method的class" + method.getClass());
System.out.println("methodProxy的class" + methodProxy.getClass());
return null;
}
}


public class Client {
public static void main(String[] args) {
ProxyFactory factory = new ProxyFactory();
TrainStation proxyObject = factory.getProxyObject();
proxyObject.sell();
}
}

# 三种代理对比

  • jdk 代理和 CGLib 代理

    使用 CGLib 代理实现动态代理,CGLib 底层采用 ASM 字节码生成框架,使用字节码技术生成代理,在 JDK1.6 之前比使用 Java 反射效率要高。唯一需要注意的是,CGLib 不能对声明为 final 的类或者方法进行代理,因为 CGLib 原理是动态生成被代理类的子类

    在 JDK1.6, JDK1.7, JDK1.8 逐步对 JDK 动态代理优化之后,在调用次数较少的情况下,JDK 代理效率高于 CGLib 代理效率,只有当进行大量调用的时候,JDK1.6 和 JDK1.7 比 CGLib 代理效率低一些,但是到了 JDK1.8 的时候,JDK 代理效率高于 CGLib 代理。所以如果有接口使用 JDK 动态代理,没有接口使用 CGLib 代理

  • 动态代理和静态代理

    动态代理与静态代理相比较,最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法进行处理。这样在接口方法数量比较多的时候,我们可以进行灵活处理,而不需要像静态代码那样每一个方法进行中转

    如果接口增加一个方法,静态代理模式除了所有实现类需要实现这个方法以外,所有的代理类也需要实现此方法。增加了代码维护的复杂度,而动态代理不会出现该问题

# 优缺点

优点 :

  • 代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用
  • 代理对象可以扩展目标对象的功能
  • 代理模式能将客户端与目标对象分离,在一定程度上降低了系统的耦合度

缺点 :

  • 增加了系统的复杂度

# 适用场景

  • 远程代理

    本地服务通过网络请求远程服务。为了实现本地到远程的通信,我们需要实现网络通信,处理其中可能的异常。为良好的代码设计和可维护性,将网络通信的部分隐藏起来,只暴露给本地服务一个接口,通过该接口即可访问远程服务器提供的功能,而不必过多关心通信部分的细节 (RPC)

  • 防火墙代理

    当将浏览器配置成使用代理功能时,防火墙就将浏览器的请求转给互联网;当互联网返回响应时,代理服务器再把它转给浏览器

  • 保护代理

    控制对一个对象的访问,如果需要,可以给不同的用户提供不同级别的使用权限

# 适配器模式

将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类能一起工作

适配器模式分为类适配器模式和对象适配器模式,前者类之间的狗和杜比后者高,且要求程序员了解现有组件库中的相关组件的内部结构,所以应用相对较少一些

适配器 (Adapter) 模式包含以下主要角色 :

  • 目标 (Target) 接口:当前业务系统所期待的接口,它可以是抽象类或接口
  • 适配者 (Adaptee) 类:它是被访问和适配的现存组件库中的组件接口
  • 适配器 (Adapter) 类:它是一个转换器,通过继承或引用适配者的对象,把适配者接口转换成目标接口,让客户按目标接口的格式访问适配者

例:现有一台电脑只能读取 SD 卡,而要读取 TF 卡中的内容的话就需要使用到适配器模式

# 类适配器模式

image-20221122174618004

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
public interface TFCard {
String readTF();
void writeTF();
}


public interface SDCard {
String readSD();
void writeSD();
}


public class SDCardImpl implements SDCard {
@Override
public String readSD() {
return "读取到SD卡内容";
}

@Override
public void writeSD() {
System.out.println("向SD卡写入内容");
}
}


public class TFCardImpl implements TFCard {
@Override
public String readTF() {
return "读取TF卡内容";
}

@Override
public void writeTF() {
System.out.println("向TF卡中写入内容");
}
}


public class SDAdapterTF extends TFCardImpl implements SDCard {
@Override
public String readSD() {
return this.readTF();
}

@Override
public void writeSD() {
this.writeTF();
}
}


public class Computer {
public String readSD(SDCard sdCard) {
return sdCard.readSD();
}
}


public class Client {
public static void main(String[] args) {
Computer computer = new Computer();
String content = computer.readSD(new SDCardImpl());
System.out.println(content);
String adaptContent = computer.readSD(new SDAdapterTF());
System.out.println(adaptContent);
}
}

类适配器模式违背了合成复用原则。类适配器是客户类有一个接口规范的情况下可用,反之不可用

# 对象适配器方式

实现方式:对象适配器模式可采用将现有组件库已经实现的组件引入适配器类中,该类同时实现当前系统的业务接口

image-20221122201520127

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class SDAdapterTF implements SDCard {
private final TFCardImpl tfCard;
@Override
public String readSD() {
return this.tfCard.readTF();
}

public SDAdapterTF(TFCardImpl tfCard) {
this.tfCard = tfCard;
}

@Override
public void writeSD() {
this.tfCard.writeTF();
}
}

# 适用场景

  • 以前开发的系统存在满足新系统功能需求的类,但其接口同新系统的接口不一致
  • 使用第三方提供的组件,但接口定义和自己要求的接口定义不同

# 装饰者模式

指在不改变现有对象结构的情况下,动态地给对象增加一些职责 (即增加其额外功能) 的模式

装饰 (Decorator) 模式中的角色 :

  • 抽象构建 (Component) 角色:定义一个抽象接口以规范准备接受附加责任的对象
  • 具体构建 (Concrete Component) 角色:实现抽象构件,通过装饰角色为其添加一些职责
  • 抽象装饰 (Decorator) 角色:继承或实现抽象构件,并包含具体构件的实例,可以通过其子类扩展具体构件的功能
  • 具体装饰 (ConcreteDecorator) 角色:实现抽象装饰的相关方法,并给具体构件对象添加附加的责任

例:快餐店有炒面,炒饭这些快餐,可以额外附加鸡蛋,火腿,培根这些配菜,加配菜需要额外价钱,每个配菜的价格通常不太一样,那么计算总价就会显得比较麻烦

image-20221123131104427

使用继承的方式存在的问题 :

  • 扩展性不好

    如果要再加一种配料,就需要给 FriedRice 和 FiredNoodles 分别定义一个子类。如果要新增一个快餐品类,就需要定义更多子类

  • 产生过多的子类

对快餐店案例进行改进 :

image-20221123131928307

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
public class Bacon extends Decorator {
public Bacon(FastFood fastFood) {
super(fastFood);
}

@Override
public double cost() {
System.out.println("加培根");
return super.cost() + 2;
}
}


public class Egg extends Decorator{
public Egg(FastFood fastFood) {
super(fastFood);
}

@Override
public double cost() {
System.out.println("加鸡蛋");
return super.cost() + 1;
}
}


public abstract class Decorator extends FastFood {
private final FastFood fastFood;

public Decorator(FastFood fastFood) {
this.fastFood = fastFood;
}

@Override
public double cost() {
return this.fastFood.cost();
}
}


public abstract class FastFood {
private String name;
private double price;

public FastFood() {
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public double getPrice() {
return price;
}

public void setPrice(double price) {
this.price = price;
}

public FastFood(String name, double price) {
this.name = name;
this.price = price;
}

public abstract double cost();
}


public class FiredNoodles extends FastFood{
public FiredNoodles() {
super("炒面", 12);
}
@Override
public double cost() {
System.out.println("炒面");
return getPrice();
}
}


public class FiredRice extends FastFood {
public FiredRice() {
super("炒饭", 10);
}

@Override
public double cost() {
System.out.println("炒饭");
return getPrice();
}
}

优点 :

  • 装饰着模式可以带来比继承更加灵活的扩展功能,使用更加方便,可以通过组合不同的装饰者对象来获取具有不同行为状态的多样化的结果。装饰者模式比继承更具良好的扩展性,完美的遵循开闭原则,继承是静态的附加责任,装饰者则是动态的附加责任
  • 装饰类和被装饰类可以独立发展,不会相互耦合,装饰者模式是继承的一个替代模式,装饰模式可以动态扩展一个实现类的功能

# 适用场景

  • 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时

    不能采用继承的情况主要有两类 :

    • 第一类是系统中存在大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长
    • 第二类是因为类定义不能继承 (如 final 类)
  • 在不影响其他对象的情况下,以动态,透明的方式给单个对象添加职责

  • 当对象的功能要求可以动态地添加,也可以再动态地撤销时

JDK 中各种输入流,输出流,字节流,字符流,缓冲流等各种各样的流,他们中许多类都是装饰者模式

# 代理和装饰者的区别

静态代理和装饰者模式的区别 :

  • 相同点 :

    • 都要实现与目标类相同的业务接口
    • 在两个类中都要声明目标对象
    • 都可以在不修改目标类的前提下增强目标方法
  • 不同点 :

    • 目的不同

      装饰者是为了增强目标对象

      静态代理是为了保护和隐藏目标对象

    • 获取目标对象的构件地方不同

      装饰者是由外界传递进来,可以通过构造方法传递

      静态代理是在代理类内部创建,以此来隐藏目标对象

# 桥接模式

将抽象与实现分离,使它们可以独立变化。它是用组合关系代替继承关系来实现,从而降低了抽象和实现这两个可变维度的耦合度

桥接 (Bridge) 模式包含以下角色 :

  • 抽象化 (Abstraction) 角色:定义抽象类,并包含一个对实现化对象的引用
  • 扩展抽象化 (Refined Abstraction) 角色:是抽象化角色的子类,实现父类中的业务方法,并通过组合关系调用实现化角色中的业务方法
  • 实现化 (Implementor) 角色:定义实现化角色的接口,供扩展抽象化角色调用
  • 具体实现化 (Concrete Implementor) 角色:给出实现化角色接口的具体实现

例:需要开发一个跨平台视频播放器,可以在不同操作平台上播放各种格式的视频文件,常见的视频格式包括 RMVB, AVI, WMV 等.

image-20221123145057608

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
51
52
53
54
55
56
57
public class AVIFile implements VideoFile{
@Override
public void decode(String filename) {
System.out.println("解码AVI");
}
}


public class RMVBFile implements VideoFile{
@Override
public void decode(String filename) {
System.out.println("解码RMVB");
}
}


public class Mac extends OperatingSystem{
public Mac(VideoFile videoFile) {
super(videoFile);
}

@Override
public void play(String filename) {
System.out.println("Mac系统");
this.videoFile.decode(filename);
}
}


public class Windows extends OperatingSystem{
public Windows(VideoFile videoFile) {
super(videoFile);
}

@Override
public void play(String filename) {
System.out.println("Windows系统");
this.videoFile.decode(filename);
}
}


public abstract class OperatingSystem {
protected VideoFile videoFile;

public OperatingSystem(VideoFile videoFile) {
this.videoFile = videoFile;
}

public abstract void play(String filename);
}


public interface VideoFile {
void decode(String filename);
}

优点 :

  • 桥接模式提高了系统的可扩充性,在两个变化维度中任意扩展一个维度,都不需要修改原有的系统
  • 实现细节对客户透明

# 适用场景

  • 当一个类存在两个独立变化的维度,且这两个维度都需要进行扩展时
  • 当一个系统不希望使用继承或因为多层继承导致整个系统类的个数急剧增加时
  • 当一个系统需要在构建的抽象化角色和具体化角色之间增加更多的灵活性时。避免在两个层次之间建立静态的继承联系,通过桥接模式可以使他们在抽象层建立一个关联关系

# 外观模式

又名门面模式,是一种通过多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易被访问的模式。该模式对外有一个统一的接口,外部应用程序不用关心内部子系统的具体实现细节,这样会大大降低应用程序的复杂度,提高了程序的可维护性

外观 (Facade) 模式是迪米特法则的典型应用

外观 (Facade) 模式包含以下角色 :

  • 外观 (Facade) 角色:为多个子系统对外提供一个共同的接口
  • 子系统 (Sub System) 角色:实现系统的部分功能,客户可以通过外观角色访问它

image-20221123151907724

例:一个人在家,每次都需要打开灯,打开电视,打开空调;睡觉时关闭灯,关闭电视,关闭空调;操作起来较为繁琐。通过一个智能音箱,可以语音控制这些家电的开启与关闭

image-20221123161925031

优点 :

  • 降低了子系统与客户端之间的耦合度,使得子系统的变化不会影响调用它的客户类
  • 对客户屏蔽了子系统组件,减少了客户处理的对象数目,并使得子系统使用起来更加容易

缺点 :

  • 不符合开闭原则,修改麻烦

# 适用场景

  • 对分层结构系统构建时,使用外观模式定义子系统中每层的入口可以简化子系统之间的依赖关系
  • 当一个复杂系统的子系统很多时,外观模式可以为系统设计一个简单的接口供外界访问
  • 当客户端与多个子系统之间存在很大的联系时,引入外观模式可将它们分离,从而提高子系统的独立性和可以执性

# 组合模式

又名部分整体模式,是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象,用来表示部分以及整体层次。这种类型的设计模式属于结构性模式,它创建了对象组的树形结构

组合模式主要包含三种角色 :

  • 抽象根节点 (Component) : 定义系统各层次对象的共有方法和属性,可以预先定义一些默认行为和属性
  • 树枝节点 (Composite) : 定义树枝节点的行为,储存子节点,组合书直接点和叶子节点形成一个树形结构
  • 叶子节点 (Leaf) : 叶子对象节点,其下再无分支,是系统层次遍历的最小单位

例:软件菜单可以包含菜单项,也可以包含含有其他菜单的菜单,因此适用组合模式描述菜单就很恰当,我们的需求是针对一个菜单,打印出其包含的所有菜单以及菜单项的名称

image-20221123170652651

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
public class Menu extends MenuComponent {
private List<MenuComponent> menuComponentList = new ArrayList<>();
public Menu(String name, int level) {
this.name = name;
this.level = level;
}

@Override
public void add(MenuComponent menuComponent) {
menuComponentList.add(menuComponent);
}

@Override
public void remove(MenuComponent menuComponent) {
menuComponent.remove(menuComponent);
}

@Override
public MenuComponent getChild(int index) {
return menuComponentList.get(index);
}

@Override
public void print() {
for (int i = 0; i < this.level; i++) {
System.out.print("---");
}
System.out.println(name);
for (MenuComponent menuComponent : menuComponentList) {
menuComponent.print();
}
}
}


public abstract class MenuComponent {
protected String name;
protected int level;

public void add(MenuComponent menuComponent) {
throw new UnsupportedOperationException();
}

public void remove(MenuComponent menuComponent) {
throw new UnsupportedOperationException();
}

public MenuComponent getChild(int index) {
throw new UnsupportedOperationException();
}

public String getName() {
return this.name;
}

public abstract void print();
}


public class MenuItem extends MenuComponent {
public MenuItem(String name, int level) {
this.name = name;
this.level = level;
}

@Override
public void print() {
for (int i = 0; i < this.level; i++) {
System.out.print("---");
}
System.out.println(this.name);
}
}


public class Client {
public static void main(String[] args) {
MenuComponent menu1 = new Menu("菜单管理", 2);
menu1.add(new Menu("页面访问", 3));
menu1.add(new Menu("展开菜单", 3));
menu1.add(new Menu("编辑菜单", 3));
menu1.add(new Menu("删除菜单", 3));
menu1.add(new Menu("新增菜单", 3));
MenuComponent menu2 = new Menu("权限管理", 2);
menu2.add(new Menu("页面访问", 3));
menu2.add(new Menu("提交保存", 3));
MenuComponent menu3 = new Menu("角色管理", 2);
menu3.add(new Menu("页面访问", 3));
menu3.add(new Menu("新增角色", 3));
menu3.add(new Menu("修改角色", 3));
MenuComponent menu = new Menu("系统管理", 1);
menu.add(menu1);
menu.add(menu2);
menu.add(menu3);
menu.add(new MenuItem("菜单项", 2));
menu.print();
}
}

# 组合模式的分类

在使用组合模式时,根据抽象构件类的定义形式,可将组合模式分为透明组合模式和安全组合模式两种形式

  • 透明组合模式

    透明组合模式中,抽象根节点角色中声明了所有用于管理成员对象的方法,比如在示例中,MenuComponent 声明了 add, remove, getChild 方法,这样做的好处是确保所有的构件都有相同的接口。透明组合模式也是组合模式的标准形式

    透明组合模式的缺点是不够安全,因为叶子节点和容器对象在本质上是有区别的,叶子对象不可能有下一个层次的对象,即不可能包含成员对象,因此为其提供 add (), remove () 等方法是没有意义的,者在编译阶段不会出错,但在运行阶段如果调用这些方法可能会出错 (如果没有提供相应的错误处理代码)

  • 安全组合模式

    在安全组合模式中,在抽象构件角色中没有声明任何用于管理成员对象的方法,而是在树枝节点 Menu 类中声明并实现这些方法。安全组合模式的缺点是不够透明,因为叶子构件和容器构建具有不同的方法,且容器构件中哪些用于管理成员对象的方法没有在抽象构件类中定义,因此客户端不能完全针对抽象编程,必须有区别地对待叶子构件和容器构件

# 享元模式

运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量。避免大量相似对象的开销,从而提高系统资源利用率

享元 (Flyweight) 模式存在以下两种状态 :

  1. 内部状态,即不会随着环境的改变而改变的可共享部分
  2. 外部状态,指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态,并将外部状态外部化.

享元模式主要有以下角色 :

  • 抽象享元角色 (Flyweight) : 通常是一个接口或抽象类,在抽象享元类中声明了具体享元类公共的方法,这些方法可以向外界提供享元对象的内部数据 (内部状态), 同时也可以通过这些方法来设置外部数据 (外部状态)
  • 具体享元 (Concrete Flyweight) 角色:它实现了抽象享元类,称为享元对象;在具体享元类中为内部状态提供了储存空间。通常可以结合单例模式来设计具体享元类,为每一个具体享元类提供唯一的享元对象
  • 非享元 (Unshareable Flyweight) 角色:并不是所有的抽象享元类的子类都需要被共享,不能被共享的子类可设计为非共享具体享元类;当需要一个非共享具体享元类的对象时可以直接通过实例化创建.
  • 享元工厂 (Flyweight Factory) 角色:负责创建和管理享元角色。当客户对象请求一个享元对象时,享元工厂检查系统中是否存在符合要求的享元对象,如果存在则提供给客户;如果不存在的话则创建一个新的享元对象

例:俄罗斯方块

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
public abstract class AbstractBox {
public abstract String getShape();

public void display(String color) {
System.out.println("方块形状: " + getShape() + ", 颜色: " + color);
}
}


public class IBox extends AbstractBox {
@Override
public String getShape() {
return "I";
}
}


public class LBox extends AbstractBox {
@Override
public String getShape() {
return "L";
}
}


public class OBox extends AbstractBox {
@Override
public String getShape() {
return "O";
}
}


public class BoxFactory {
private static BoxFactory boxFactory;
private HashMap<String, AbstractBox> map;

private BoxFactory() {
this.map = new HashMap<>();
map.put("I", new IBox());
map.put("L", new LBox());
map.put("O", new OBox());
}

public static BoxFactory getInstance() {
if (boxFactory == null) {
synchronized (BoxFactory.class) {
if (boxFactory == null) {
boxFactory = new BoxFactory();
}
}
}
return boxFactory;
}

public AbstractBox getShape(String name) {
return map.get(name);
}
}


public class Client {
public static void main(String[] args) {
BoxFactory factory = BoxFactory.getInstance();
AbstractBox L = factory.getShape("L");
L.display("灰色");
}
}

优点 :

  • 极大减少内存中相似或相同的对象数量,节约系统资源,提供系统性能
  • 享元模式中的外部状态相对孤立,且不影响内部状态

缺点 :

  • 为了使对象可以共享,需要将享元对象的部分状态外部化,分离内部状态和外部状态,使程序逻辑复杂

# 适用场景

  • 一个系统有大量相同或者相似的对象,造成内存的大量耗费
  • 对象的大部分状态都可以外部化,可以将这些外部状态传入对象中
  • 在适用享元模式时需要维护一个储存享元对象的享元池,而这需要耗费一定的系统资源,因此,应当在需要多次重复适用享元对象时才值得使用享元模式