文章目录
结构型模式
结构型模式描述如何将类或对象按某种布局组成更大地结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者采用组合或聚合来组成对象。
由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式更具有灵活性。
结构型模式分为以下7种:
- 代理模式
- 适配器模式
- 装饰者模式
- 桥接模式
- 外观模式
- 组合模式
- 享元模式
代理模式
概述
由于某些原因,需要给某对象提供一个代理以控制对该对象的访问。这时,访问对象不适合或者不能直接引用目标对象,代理对象作为访问对象和目标对象之间的中介。(目标对象:电脑厂,访问对象:买家,代理对象:商家)
Java中的代理按照代理类生成时机不同又分为静态代理和动态代理。静态代理:代理类在编译期就生成,而动态代理则是在Java运行时动态生成,动态代理又有JDK代理和CGLib代理两种。
组成
代理模式分为3种角色:
- 抽象主题(Subject)类:通过接口或抽象类声明真实主题和代理对象实现的业务方法。
- 真实主题(Real Subject)类:实现了抽象主题中的具体业务,是代理对象所代表的真实对象,是最终要引用的对象。
- 代理(Proxy)类:提供了与真实主题相同的接口,其内部含有对真实主题的引用,它可以访问,控制或扩展真实主题的功能。
静态代理
通过案例来说明:
火车站卖票:如果要买火车票的话,需要去火车站买票,坐车到火车站,排队等一系列的操作,显然比较麻烦。而火车站在多个地方都有代售点,我们去代售点买票就方便很多了。这个例子其实就是典型的代理模式,火车站是目标对象,代售点是代理对象,类图如下:
代码实现:
// 抽象主题
public interface SellTickets {
void sell();
}
// 真实主题
public class TrainStation implements SellTickets{
@Override
public void sell() {
System.out.println("火车站卖票");
}
}
// 代理
public class ProxyPoint implements SellTickets{
//声明火车站类对象 聚合
private TrainStation trainStation = new TrainStation();
@Override
public void sell() {
System.out.println("代售点收取一些服务费");
trainStation.sell();
}
}
测试类:
public class StaticProxyTest {
public static void main(String[] args) {
//创建代售点类对象
ProxyPoint proxyPoint = new ProxyPoint();
//调用方法进行买票
proxyPoint.sell();
}
}
从上面代码中可以看出,测试类直接访问的是ProxyPoint类对象,也就是说ProxyPoint 作为访问对象和目标对象的中介。同时也对sell方法进行了一些增强(代售点收取一些服务费).
JDK动态代理
我们使用动态代理实现上面案例,先说说JDK提供的动态代理,Java中提供了一个动态代理类Proxy,Proxy并不是我们上述所说的代理对象的类,而是提供了一个创建代理对象的静态方法(newProxyInstance方法)来获取代理对象。
代码说明:
// 卖火车票接口 抽象主题
public interface SellTickets {
void sell();
}
// 火车站类 真实主题
public class TrainStation implements SellTickets {
@Override
public void sell() {
System.out.println("火车站卖票");
}
}
// 获取代理对象的工厂类
public class ProxyFactory {
//声明目标对象
private TrainStation trainStation= new TrainStation();
/**
* ClassLoader loader : 类加载器,用于加载代理类,可以通过目标对象获取类加载器
* Class<?>[] interfaces : 代理类实现的接口的字节码对象
* InvocationHandler h : 代理对象的调用处理程序
* @return
*/
public SellTickets getProxyObject(){
//返回代理对象
SellTickets proxyObj=(SellTickets)Proxy.newProxyInstance(
trainStation.getClass().getClassLoader(),
trainStation.getClass().getInterfaces(),
new InvocationHandler() {
/**
*
* @param proxy : 代理对象,和proxyObj对象是同一个对象,在invoke方法中基本不用
* @param method : 对接口中的方法进行封装的method对象
* @param args : 调用方法的实际参数
* @return : 就是方法的返回值,这里指 sell()的返回值
* @throws Throwable
*/
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
//System.out.println("invoke执行了");
System.out.println("代售点收取一些服务费(JDK动态代理)");
Object object = method.invoke(trainStation, args);
return object;
}
}
);
return proxyObj;
}
}
测试:
public class JdkProxyTest {
public static void main(String[] args) {
//获取代理对象
//1. 创建代理工厂对象
ProxyFactory proxyFactory = new ProxyFactory();
//2. 使用factory对象的方法获取代理对象
SellTickets proxyObject = proxyFactory.getProxyObject();
//3. 调用卖票的方法
proxyObject.sell();
}
}
使用了动态代理,我们思考下面的问题:
- ProxyFactory是代理类吗?
ProxyFactory不是代理模式中所说的代理类,而代理类是程序在运行过程中动态的在内存中生成的类。
诊断工具(Arthas)查看代理类的结构:
源码:
package com.sun.proxy;
import com.ming.structure.proxy.jdk_proxy.SellTickets;
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 Method m1;
private static Method m2;
private static Method m3;
private static Method m0;
public $Proxy0(InvocationHandler invocationHandler) {
super(invocationHandler);
}
static {
try {
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.ming.structure.proxy.jdk_proxy.SellTickets").getMethod("sell", new Class[0]);
m0 = Class.forName("java.lang.Object").getMethod("hashCode", 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);
}
}
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)将我们提供了的匿名内部类对象传递给了父类
动态代理的执行流程是什么样的?
简化后的源码:
public final class $Proxy0 extends Proxy implements SellTickets {
private static Method m3;
public $Proxy0(InvocationHandler invocationHandler) {
super(invocationHandler);
}
static {
m3 = Class.forName("com.ming.structure.proxy.jdk_proxy.SellTickets").getMethod("sell", new Class[0]);
}
public final void sell() {
this.h.invoke(this, m3, null);
}
}
//Java提供的动态代理相关类
public class Proxy implements java.io.Serializable{
protected InvocationHandler h;
protected Proxy(InvocationHandler h){
this.h = h;
}
执行流程如下:
- 在测试类中通过代理对象调用sell()方法。
- 根据多态的特性,执行的是代理类($Proxy0)中的sell()方法。
- 代理类($Proxy0)中的sell()方法中又调用InvocationHandler接口的子实现类对象的invoke方法。
- invoke方法通过反射执行了真实对象所属类(TrainStation)中的sell()方法。
CGLIB动态代理
同样是上面的案例,我们再次使用CGLIB动态代理实现。
如果没有定义SellTickets接口,只定义了TrainStation(火车站类),很显然JDK代理是无法使用了,因为JDK动态代理要求必须定义接口,对接口进行代理。
CGLIB是一个功能强大,高性能的代码生成包。它为没有实现接口的类提供代理,为JDK的动态代理提供了很好的补充。
CGLIB是第三方提供的包,所以需要引入jar包的坐标:
<dependency>
<groupId>cglib</groupId>
<artifactId>cglib</artifactId>
<version>3.1</version>
</dependency>
代码实现:
// 真实主题
public class TrainStation {
public void sell() {
System.out.println("火车站卖票");
}
}
// 代理生成工厂
public class ProxyFactory implements MethodInterceptor {
//声明火车站对象
private TrainStation station = new TrainStation();
//用来获取代理对象
public TrainStation getProxyObject(){
//创建Enhancer对象,类似与JDK代理的Proxy类
Enhancer enhancer = new Enhancer();
//设置父类的字节码对象,指定父类,TrainStation
enhancer.setSuperclass(TrainStation.class);
//设置回调函数, 体现多态 setCallback(Callback callback)
enhancer.setCallback(this);
//创建代理对象
TrainStation proxyObj=(TrainStation)enhancer.create();
return proxyObj;
}
//与JDK代理中的 invoke() 方法类似
@Override
public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
//System.out.println("该方法执行了");
System.out.println("代售点收取一些服务费(CGLIB动态代理)");
Object obj = method.invoke(station, objects);
return obj;
}
}
测试类:
public class CglibProxyTest {
public static void main(String[] args) {
//获取代理对象
//1. 创建代理工厂对象
ProxyFactory proxyFactory = new ProxyFactory();
//2. 使用factory对象的方法获取代理对象
TrainStation proxyObject = proxyFactory.getProxyObject();
//3. 调用卖票的方法
proxyObject.sell();
}
}
三种代理的对比
- jdk代理和CGLIB代理
使用CGLIB实现动态代理,CGLIB底层采用字节码生成框架,使用字节码技术生成代理类,在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代理。
- 动态代理和静态代理
动态代理与静态代理相比较,最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法中处理(InvocationHandler.invoke)。这样,在接口方法数量较多的时候,我们可以进行灵活处理,而不需要像静态代理那样每一个方法进行中转。
如果接口增加一个方法,静态代理除了所有实现类需要实现这个方法外,所有代理类也需要实现此方法。增加了代码维护的复杂度。而动态代理不会出现该问题。
优缺点
优点:
- 代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用;
- 代理对象可以扩展目标对象的功能;
- 代理模式能将客户端与目标对象分离,在一定程度上降低了系统的耦合度;
缺点 - 增加了系统的复杂度;
使用场景:
-
远程代理:
本地服务通过网络请求远程服务,为了实现本地到远程的通信,我们需要实现网络通信,处理其中可能的异常。为良好的代码设计和可维护性,我们将网络通信部分隐藏起来,只暴露给本地服务一个接口,通过该接口即可访问远程服务提供的功能,而不必过多关心通信部分的细节。 -
防火墙代理:
当你将浏览器配置成使用代理功能时,防火墙就将你的浏览器的请求转交给互联网,当互联网返回响应时,代理服务器再把它转给你的浏览器 -
保护代理:
控制对一个对象的访问,如果需要,可以给不同的用户提供不同级别的使用权限。
适配器模式
概述
如果去欧洲国家旅游的话,他们的插座是欧洲标准(三孔),而我们使用的是标准的交流电插头(二脚),因此我们的笔记本电脑,手机在当地不能直接充电,所以就需要一个插座转换器,转换器第一面插入当地的插座,第2面供我们充电,这样使得我们的插头在当地能使用。再比如手机充电器(将220V转换为5V),读卡器等。其实就是使用到了适配器模式。
定义:
将一个类的接口转换为客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
适配器模式分为类适配器和对象适配器。前者类之间的耦合度比后者高,且要求程序员了解现有组件库中相关组件的内部结构,所以应用相对较少些。
组成
适配器模式(Adapter)分为三个角色:
- 目标接口(Target) :当前系统业务所期待的接口,它可以是抽象类或接口。
- 适配者类(Adaptee):它是被访问和适配的现存组件库中的组件接口。
- 适配器类(Adapter):它是一个转换器,通过继承或引用适配者的对象,把适配者接口转化成目标接口,让客户按目标接口的格式访问适配者。
类适配器模式:
实现方式:定义一个适配器类来实现当前系统的业务接口,同时又继承现有组件库中已经存在的组件。
【例】读卡器
现有一台电脑只能读取SD卡,而要读取TF卡中的内容的话,就需要使用到适配器模式,创建一个读卡器,将TF卡中的内容读取出来,类图如下:
// 目标接口
public interface SDCard {
//从SD卡中读取数据
String readSD();
//从SD卡中写数据
void writeSD(String msg);
}
// 目标接口实现类
public class SDCardImpl implements SDCard{
@Override
public String readSD() {
String msg="SDCard read msg: hello world SDCard";
return msg;
}
@Override
public void writeSD(String msg) {
System.out.println("SDCard write msg:"+msg);
}
}
// 适配者类接口
public interface TFCard {
//从TF卡中读取数据
String readTF();
//从TF卡中写数据
void writeTF(String msg);
}
// 适配者类
public class TFCardImpl implements TFCard{
@Override
public String readTF() {
String msg="TFCard read msg: hello world TFCard";
return msg;
}
@Override
public void writeTF(String msg) {
System.out.println("TFCard write msg:"+msg);
}
}
// 计算机类
public class Computer {
//从SD卡中读取数据
public String readSD(SDCard sdCard){
if(sdCard==null){
throw new NullPointerException("sd card is not null");
}
return sdCard.readSD();
}
}
// 适配器类
public class SDAdapterTF extends TFCardImpl implements SDCard{
@Override
public String readSD() {
System.out.println("适配器类调用TF");
return readTF();
}
@Override
public void writeSD(String msg) {
System.out.println("适配器类调用TF");
writeTF(msg);
}
}
测试类:
public class ClassAdapterTest {
public static void main(String[] args) {
//创建计算机对象
Computer computer = new Computer();
//调用计算机对象读取SD卡中的数据
String msg = computer.readSD(new SDCardImpl());
System.out.println(msg);
System.out.println("===========");
//读取TF卡中的数据
//创建适配器对象
SDAdapterTF sdAdapterTF = new SDAdapterTF();
String msg1 = computer.readSD(sdAdapterTF);
System.out.println(msg1);
}
}
类适配器违背了合成复用原则。类适配器是客户类有一个接口规范(SDCard)的情况下可用,反之不可用,即如果没有SDCard接口,就无法实现适配器类。
对象适配器模式
实现方式:对象适配器模式可采用将现有组件库中已经实现的组件引入适配器类中(聚合),该类同时实现当前系统的业务接口。
接口适配器模式:
实现方式:当不需要全部实现接口提供的方法时,可先设计一个抽象类实现接口,并为该接口中每个方法提供一个默认实现,那么该抽象类的子类可有选择地覆盖父类地某些方法来实现需求。
代码实现:
// 目标接口(原有抽象产品)
public interface SDCard {
//从SD卡中读取数据
String readSD();
//从SD卡中写数据
void writeSD(String msg);
}
// 目标接口实现类 (原有具体产品)
public class SDCardImpl implements SDCard {
@Override
public String readSD() {
String msg="SDCard read msg: hello world SDCard";
return msg;
}
@Override
public void writeSD(String msg) {
System.out.println("SDCard write msg:"+msg);
}
}
// 计算机类(原有设备)
public class Computer {
//从SD卡中读取数据
public String readSD(SDCard sdCard){
if(sdCard==null){
throw new NullPointerException("sd card is not null");
}
return sdCard.readSD();
}
//写入msg到SD卡
public void writeSD(SDCard sdCard,String msg){
if(sdCard==null){
throw new NullPointerException("sd card is not null");
}
sdCard.writeSD(msg);
}
}
// 适配者类接口
public interface TFCard {
//从TF卡中读取数据
String readTF();
//从TF卡中写数据
void writeTF(String msg);
}
// 抽象类
public abstract class TFAbsCard implements TFCard{
@Override
public String readTF() {
System.out.println("抽象类 默认实现 ");
return null;
}
@Override
public void writeTF(String msg) {
System.out.println("抽象类 默认实现 ");
}
}
// 适配器
public class SDAdapterTF implements SDCard {
//声明适配者类
private TFAbsCard tfAbsCard;
public SDAdapterTF(TFAbsCard tfAbsCard){
this.tfAbsCard=tfAbsCard;
}
@Override
public String readSD() {
System.out.println("接口 适配器类调用TF");
return tfAbsCard.readTF();
}
@Override
public void writeSD(String msg) {
System.out.println("接口 适配器类调用TF");
tfAbsCard.writeTF(msg);
}
}
// 适配者类(现有产品)
public class TFCardImpl extends TFAbsCard {
@Override
public String readTF() {
String msg="TFCard read msg: hello world TFCard";
return msg;
}
// writeTF() 方法不想实现就可以省略
// @Override
// public void writeTF(String msg) {
// System.out.println("TFCard write msg:"+msg);
// }
}
测试类:
public class InterfaceAdapterTest {
public static void main(String[] args) {
//创建计算机对象
Computer computer = new Computer();
//调用计算机对象读取SD卡中的数据
String msg = computer.readSD(new SDCardImpl());
System.out.println(msg);
computer.writeSD(new SDCardImpl(),"SD card write mag");
System.out.println("===========");
//读取TF卡中的数据
//创建适配器对象
SDAdapterTF sdAdapterTF = new SDAdapterTF(new TFCardImpl());
String msg1 = computer.readSD(sdAdapterTF);
System.out.println(msg1);
computer.writeSD(sdAdapterTF,"TF card write msg"); //在外部包的类没有实现 writeSD() 方法,所以调用抽象父类默认实现的方法。
}
}
应用场景
- 以前开发的系统存在满足新系统功能需求的类,但其接口同新系统的接口不一致。(尽量不修改原有的系统,满足开闭原则)
- 使用第三方提供的组件,但组件接口定义和自己要求的接口定义不同。
JDK源码解析
Reader(字符流)、InputStream(字节流)的适配器使用的是InputStreamReader(将字节转换成字符)。
InputStreamReader继承自java.io包中的Reader,对他中的抽象的未实现的方法给出实现,如:
public class InputStreamReader extends Reader {
private final StreamDecoder sd;
public int read() throws IOException {
return sd.read();
}
public int read(char cbuf[], int offset, int length) throws IOException {
return sd.read(cbuf, offset, length);
}
}
如上代码中的sd,在Sun的JDK实现中,实际的方法实现是对sun.nio.cs.StreamDecoder类的同名方法的调用封装,类结构图如下:
从上图可以看出:
- InputStreamReader 是对同样实现了Reader的StreamDecoder的封装。
- StreamDecoder不是Java SE API的内容,是Sun JDK给出的自身实现。但我们知道他们对构造方法中的字节流类(InputStream)进行封装,并通过该类进行了字节流和字符流之间的解码转换。
- StreamDecoder :适配器类
- Reader :目标接口
- InputStream:适配者类
结论:
从表层来看,InputStreamReader做了InputStream字节流到Reader字符流直接的转换,而从如上Sun JDK中的实现类关系结构中可以看出,是StreamDecoder的设计实现在实际上采用了(对象)适配器模式。
装饰者模式
概述
先看一个快餐店的例子:
快餐店有炒面,炒饭这些快餐,可以额外附加鸡蛋,火腿,培根这些配菜,当然加配菜需要额外加钱,每个配菜的价格通常不太一样,那么计算总价就会显得比较麻烦
使用继承的方式存在的问题:
- 扩展性不好,如果要再加一种配料(火腿肠),我们就会发现需要给FriedRice和FriedNoodles分别定义一个子类。如果要新增一个快餐品类(炒河粉)的话,就需要更多的子类
- 产生过多的子类
定义:
指在不改变现有对象结构的情况下,动态地给对象增加一些职责(即增加其额外功能)的模式。
组成
装饰者(Decorator)模式中的角色:
- 抽象构件(Component)角色:定义一个抽象接口以规范准备接收附加责任的对象
- 具体构件(Concrete Component)角色:实现抽象构件,通过装饰角色为其添加一些职责
- 抽象装饰(Decorator)角色:继承或实现抽象构件,并包含具体构件的实例,可以通过其子类扩展具体构件的功能
- 具体装饰(ConcreteDecorator)角色:实现抽象装饰的相关方法,并给具体构件对象添加附加的责任。
案例
我们使用装饰者模式对快餐店进行改进,体会装饰者模式的精髓。
类图如下:
代码:
/**
* @Author: mei_ming
* @DateTime: 2022/12/7 20:41
* @Description: 快餐类(抽象构件角色)
*/
public abstract class FastFood {
public String desc; // 描述
public float price=0.0f; // 价格
// 计算花费
public abstract float cost();
public String getDesc() {
return desc;
}
public void setDesc(String desc) {
this.desc = desc;
}
public float getPrice() {
return price;
}
public void setPrice(float price) {
this.price = price;
}
}
/**
* @Author: mei_ming
* @DateTime: 2022/12/7 20:53
* @Description: 炒面类(具体构件角色)
*/
public class FriedNoodles extends FastFood {
public FriedNoodles(){
setPrice(7);
setDesc("炒面");
}
@Override
public float cost() {
return super.getPrice();
}
}
/**
* @Author: mei_ming
* @DateTime: 2022/12/7 20:50
* @Description: 炒饭类(具体构件角色)
*/
public class FriedRice extends FastFood {
public FriedRice(){
setPrice(10);
setDesc("炒饭");
}
@Override
public float cost() {
return super.getPrice();
}
}
/**
* @Author: mei_ming
* @DateTime: 2022/12/7 20:43
* @Description: 装饰者类(抽象装饰角色) 即继承又组合
*/
public class Garnish extends FastFood {
public FastFood fastFood;
public Garnish(FastFood fastFood) { // 组合
this.fastFood = fastFood;
}
@Override
public float cost() {
// getPrice(): 自己调料类的价格
// fastFood.cost() : 产品的价格
return super.getPrice() + fastFood.cost();
}
// 描述
@Override
public String getDesc() {
// super.getDesc() : 调味料的描述
// super.getPrice() : 调味料的价格
// fastFood.getDesc() : 产品的描述
return super.getDesc() + " " + super.getPrice() + " && " + fastFood.getDesc();
}
}
/**
* @Author: mei_ming
* @DateTime: 2022/12/7 21:04
* @Description: 鸡蛋类(具体装饰角色)
*/
public class Egg extends Garnish{
public Egg(FastFood fastFood) {
super(fastFood);
setDesc("鸡蛋");
setPrice(1.0f);
}
}
/**
* @Author: mei_ming
* @DateTime: 2022/12/7 21:06
* @Description: 培根类(具体装饰角色)
*/
public class Bacon extends Garnish{
public Bacon(FastFood fastFood) {
super(fastFood);
setDesc("培根");
setPrice(2.0f);
}
}
测试代码:
/**
* @Author: mei_ming
* @DateTime: 2022/12/7 21:08
* @Description: 商店(测试端)
*/
public class Store {
public static void main(String[] args) {
// 想要一个加两个鸡蛋一个培根的炒面
// 1. 先装个炒面
FastFood friedNoodles = new FriedNoodles();
System.out.println("1. "+friedNoodles.getDesc()+" 花费= " + friedNoodles.cost()+"元");
// 2. 加入一个培根
friedNoodles = new Bacon(friedNoodles);
System.out.println("2. "+friedNoodles.getDesc()+" 花费= " + friedNoodles.cost()+"元");
// 3. 加入一个鸡蛋
friedNoodles = new Egg(friedNoodles);
System.out.println("3. "+friedNoodles.getDesc()+" 花费= " + friedNoodles.cost()+"元");
// 4. 加入一个鸡蛋
friedNoodles = new Egg(friedNoodles);
System.out.println("4. "+friedNoodles.getDesc()+" 花费= " + friedNoodles.cost()+"元");
/**
* 1.炒面 花费= 7.0元
* 2.培根 2.0 && 炒面 花费= 9.0元
* 3.鸡蛋 1.0 && 培根 2.0 && 炒面 花费= 10.0元
* 4.鸡蛋 1.0 && 鸡蛋 1.0 && 培根 2.0 && 炒面 花费= 11.0元
*/
}
}
好处
- 装饰模式可以带来比继承更加灵活性的扩展功能,使用更加方便,可以通过组合不同的装饰者对象来获取具有不同行为状态的多样化的结果。装饰者模式比继承更有良好的扩展性,完美的遵循了开闭原则,继承是静态的附加责任,装饰者则是动态的附加责任。
- 装饰类和被装饰类可以独立发展,不会相互耦合,装饰模式是继承的一个替代模式,装饰模式可以动态扩展一个实现类的功能。
使用场景
-
当不能采用继承的方式对系统进行扩充或采用继承不利于系统扩展和维护时。
不能采用继承的情况主要有两种:- 第一类是系统中存在大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目爆炸性增长;
- 第二类是因为类定义不能继承(如final类)
-
在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责
-
当对象的功能要求可以动态地添加,也可以再动态地撤销时。
JDK 源码解析(IO流内部的装饰者模式)
如上类图所示:FilterInputStream就是一个装饰者,他既继承了InputStream,又组合了InputStream。
代码说明:
import java.io.DataInputStream;
import java.io.FileInputStream;
/**
* @Author: mei_ming
* @DateTime: 2022/12/7 22:36
* @Description: 装饰者模式源码分析
*/
public class Decorator {
public static void main(String[] args) throws Exception{
/**
* 说明:
* 1. InputStream 是抽象类,类似于 FastFood
* 2. FileInputStream 是InputStream的子类,类似于 FriedRice
* 3. FilterInputStream 是InputStream的子类,类似于 Garnish 装饰者类
* 4. DataInputStream 是FilterInputStream的子类,具体的装饰者,类似于 Egg
* 5. FilterInputStream 类 有 protected volatile InputStream in; 即含有被装饰者(组合)
* 6. 分析得出在jdk的io体系中,就是使用的装饰者模式
*/
DataInputStream dis = new DataInputStream(new FileInputStream("d:\\abc.txt"));
System.out.println(dis.read());
dis.close();
}
}
代理和装饰者的区别
静态代理和装饰者模式的区别:
相同点:
- 都要实现与目标类相同的业务接口
- 在两个类都要声明目标对象
- 都可以在不修改目标类的前提下增强方法
不同点:
- 目的不同
- 装饰者是为了增强目标对象
- 静态代理是为了保护和隐藏目标对象
- 获取目标对象构建的地方不同
- 装饰者是由外界传递进来,可以通过构造方法传递(装饰者是运行时增强,只有运行时才知道具体增强的目标)
- 静态代理是在代理类内部创建,以此来隐藏目标对象(静态代理是一种编译期增强,还没运行就已经知道增强的目标对象)
桥接模式
概述
现有一个需求,需要创建不同图形,并且每个图形都会有可能会有不同的颜色,我们可以利用继承的方式来设计类的关系:
我们可以发现有很多的类,假如我们再增加一个形状或再增加一种颜色,就需要创建更多的类。
试想,在一个有多种会变化的维度的系统中,用继承方式会造成类爆炸,扩展起来不灵活。每次在一个维度上新增一个具体实现都要增加多个子类。为了更加灵活的设计系统,我们此时可以考虑使用桥接模式。
定义:
- 是一种结构型设计模式
- 基于类的最小设计原则,通过使用封装、聚合及继承等行为让不同的类承担不同的职责,最主要的特点使把抽象与行为实现分离
- 将抽象与实现放在不同的类层次中,使两个层次可以独立改变
- 它是用组合关系代替继承关系来实现,从而降低了抽象和实现这两个可变维度的耦合度。
组成
桥接(Bridge)模式包含以下主要角色:
- 抽象化(Abstraction)角色:定义抽象类,并包含一个对实现化对象的引用 (桥角色)
- 扩展抽象化(Refined Abstraction)角色:是抽象化角色的子类,实现父类中的业务方法,并通过组合关系调用实现化角色中的业务方法
- 实现化(Implementor)角色:定义实现化角色的接口,供扩展抽象化角色调用
- 具体实现化(Concrete Implementor)角色:给出实现化角色接口的具体实现
案例
【例】视频播放器
需要开发一个跨平台视频播放器,可以在不同操作系统平台(如Windows、Mac)上播放多种格式的视频文件,常见的视频格式包括RMVB、AVI、WMV等,该播放器包含了两个维度,适合使用桥接模式。
类图如下:
代码说明:
// 抽象的操作系统类(抽象化角色)(桥梁)
public abstract class OperatingSystem {
protected VideoFile videoFile;
public OperatingSystem(VideoFile videoFile){
this.videoFile = videoFile;
}
public void play(String fileName){
this.videoFile.decode(fileName);
}
}
// Mac系统(扩展抽象化角色)
public class Mac extends OperatingSystem{
public Mac(VideoFile videoFile) {
super(videoFile);
}
@Override
public void play(String fileName) {
super.play(fileName);
System.out.println("Mac playing");
}
}
// Windows系统(扩展抽象化角色)
public class Windows extends OperatingSystem {
public Windows(VideoFile videoFile) {
super(videoFile);
}
@Override
public void play(String fileName) {
super.play(fileName);
System.out.println("windows playing");
}
}
// 视频文件(实现化角色)
public interface VideoFile {
//解码功能
void decode(String fileName);
}
// avi视频文件(具体实现化角色)
public class AVIFile implements VideoFile{
@Override
public void decode(String fileName) {
System.out.println("AVI file :"+fileName);
}
}
// rmvb视频文件(具体实现化角色)
public class RMVBFile implements VideoFile {
@Override
public void decode(String fileName) {
System.out.println("RMVB file :"+fileName);
}
}
测试类:
public class BridgeTest {
public static void main(String[] args) {
// 使用Windows系统打开AVI格式的视频
OperatingSystem os = new Windows(new AVIFile());
os.play("abc.avi");
System.out.println("------------");
// 使用Windows系统打开RMVB格式的视频
OperatingSystem os1 = new Windows(new RMVBFile());
os1.play("abc.rmvb");
}
}
好处:
- 桥接模式提高了系统的可扩充性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统
如:如果要增加一种视频文件类型wmv,只需要再定义一个类实现VideoFile
接口即可,其他类不需要变化, - 实现细节对客户透明
注意事项和细节
- 实现了抽象和实现部分的分离,从而极大的提供了系统的灵活性,让抽象部分和实现部分独立开来,这有助于系统进行分层设计,从而产生更好的结构化系统。
- 对于系统的高层部分,只需要知道抽象部分和实现部分的接口就可以了,其他的部分由具体业务来完成
- 桥接模式代替多层继承方案,可以减少子类的个数,降低系统的管理和维护成本。
- 桥接模式的引入,增加了系统的理解和设计难度,由于聚合关联关系建立在抽象层。要求开发者针对抽象进行设计和编程。
使用场景
- 当一个类存在两个独立变化的维度,且这两个维度都需要进行扩展时。
- 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时
- 当一个系统需要再构件的抽象化角色和具体化角色之间增加更多的灵活性时,避免再两个层次之间建立静态的继承关系,通过桥接模式,可以使它们再抽象层建立一个关联关系。
外观模式
概述
在生活中,通常有不同的遥控器,来控制各类电器的开关,但是这样的体验不好,有多个遥控器。我们可以定义一个高层接口,给子系统中的一组接口提供一个一致的界面,用来访问子系统中的一群接口。(可以屏蔽内部子系统的细节)
定义:
又称为门面模式,使一种通过为多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易被访问的模式。该模式对外有一个统一的接口,外部应用程序不用关心子系统的具体细节,这样会降低应用程序的复杂度,提高了程序的可维护性。
外观模式(Facade)是迪米特法则的典型应用
组成
外观模式包含以下主要角色:
- 外观(Facade)角色:为多个子系统对外提供一个共同的接口
- 子系统(Sub System)角色:实现系统的部分功能,客户可以通过外观角色访问它
案例
【例】智能家电控制
小明的爷爷已经60岁了,一个人在家生活,每次都需要打开灯,打开电视,打开空调;睡觉时关闭灯、关闭电视、关闭空调;操作起来都比较麻烦。所以小明给爷爷买了智能音箱,可以通过语音直接控制这些智能家电的开启和关闭,类图如下:
代码说明:
// 空调类(子系统角色)
public class AirCondition {
public void on(){
System.out.println("打开空调~~");
}
public void off(){
System.out.println("关闭空调~~");
}
}
// 电灯类(子系统角色)
public class Light {
public void on(){
System.out.println("打开电灯~~");
}
public void off(){
System.out.println("关闭电灯~~");
}
}
// 电视类(子系统角色)
public class TV {
public void on(){
System.out.println("打开电视~~");
}
public void off(){
System.out.println("关闭电视~~");
}
}
// 智能音箱(外观类)
public class SmartAppliancesFacade {
public TV tv;
public Light light;
public AirCondition airCondition;
public SmartAppliancesFacade(){
tv=new TV();
light=new Light();
airCondition = new AirCondition();
}
public void say(String msg){
if(msg.contains("打开")){
on();
}else if(msg.contains("关闭")){
off();
}else{
System.out.println("其余功能未开发");
}
}
private void off() {
tv.off();
light.off();
airCondition.off();
}
private void on() {
tv.on();
light.on();
airCondition.on();
}
}
测试:
public class FacadeTest {
public static void main(String[] args) {
SmartAppliancesFacade facade = new SmartAppliancesFacade();
facade.say("打开");
System.out.println("-------------");
facade.say("关闭");
}
}
优点:
- 降低了子系统与客户端之间的耦合度,使得子系统的变化不会影响调用它的客户类
- 对客户屏蔽了子系统组件,减少了客户处理的对象数目,并使得子系统使用起来更加容易
缺点: - 不符合开闭原则,修改很麻烦
使用场景
- 对分层结构系统构建时,使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
- 当一个复杂系统的子系统很多时,外观模式可以为系统设计一个简单的接口供外界访问。
- 当客户端与多个子系统之间存在很大的联系时,引入外观模式可以将们分离,从而提高子系统的独立性和可移植性。
源码分析
使用tomcat作为web容器时,接收浏览器发送过来的请求,tomcat会将请求信息封装成ServletRequest对象,如下图①处对象。但是ServletRequest是一个接口,它还有一个子接口HttpServletRequest,而我们知道该request对象肯定是一个HttpServletRequest对象的子实现类对象,到底是哪个类的对象呢,我们就会发现是一个名为RequestFacade
的类的对象
RequestFacade类就是使用了外观模式。先看结构图:
PS:
RequestFacade:属于外观角色对象,Request:属于子系统角色。
为什么在此处使用外观模式呢?
定义RequestFacade类,分别实现ServletRequest、HttpServletRequest。同时定义私有成员变量Request,并且方法的实现调用Request的实现。然后,将RequestFacade上转为ServletRequest传给servlet的service()方法,这样即使在servlet中被下转为RequestFacade时,也不能访问私有成员变量中的方法,既用了Request,又能防止其中方法被不合理的访问。
组合模式
概述
对于上图这样的结构我们称之为树形结构。在树形结构中可以通过调用某个方法来遍历整个树,也可以增加文件/文件夹,删除文件/文件夹。当我们在实现的过程中,要区分该节点是文件(叶子节点)还是文件夹(非叶子节点)。一个文件夹还可以存放文件和文件夹。可以使用组合模式来实现对节点的各种操作。
定义:
- 组合模式(Composite Pattern),又叫部分整体模式,它创建了对象组的树形结构,将对象组合成树状结构以表示“整体-部分”的层次关系
- 组合模式依据树形结构来组合对象,用来表示部分以及整体的层次。
- 这种类型属于结构型模式
- 组合模式使得用户对单个对象和组合对象的访问具有一致性,即,组合能让客户以一致的方式处理个别对象以及组合对象
组成
组合模式主要包括三种角色:
- 抽象根节点:定义系统各层次对象的共有方法和属性,可以预先定义一些默认行为和属性。
- 树枝节点:定义树枝节点的行为,存储叶子节点,组合树枝节点和叶子节点形成一个树形结构。
- 叶子节点:叶子节点其下再无分支,是系统层次遍历的最小单位。
案例实现
【例】软件菜单
如下图,我们在访问别的一些管理系统时,经常可以看见类似的菜单。一个菜单可以包含菜单项(菜单项是不再包含其他内容的菜单条目),也可以带有其他菜单项的菜单,因此使用组合模式描述菜单就很恰当,我们的需求是针对一个菜单,打印出其包含的所有菜单以及菜单项。
要实现该案例,我们先画出类图:
代码实现:
// 菜单组件(抽象根节点)
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 name;
}
// 打印菜单名称
public abstract void print();
}
// 菜单类(树枝节点)
public class Menu extends MenuComponent {
// 菜单可以有多个子菜单或子菜单项
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) {
menuComponentList.remove(menuComponent);
}
@Override
public MenuComponent getChild(int index) {
return menuComponentList.get(index);
}
@Override
public void print() {
for (int i = 0; i <level ; i++) {
System.out.print("--");
}
// 打印菜单名称
System.out.println(name);
// 打印子菜单或者子菜单项
for (MenuComponent menuComponent : menuComponentList) {
menuComponent.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 <level ; i++) {
System.out.print("--");
}
// 打印菜单项的名称
System.out.println(name);
}
}
测试:
public class CompositeTest {
public static void main(String[] args) {
// 创建1级菜单
Menu rootMenu = new Menu("系统管理", 1);
// 创建2级菜单
Menu menu1 = new Menu("菜单管理", 2);
// 添加3级菜单
menu1.add(new MenuItem("页面访问",3));
menu1.add(new MenuItem("展开菜单",3));
menu1.add(new MenuItem("编辑菜单",3));
menu1.add(new MenuItem("删除菜单",3));
menu1.add(new MenuItem("新增菜单",3));
// 创建2级菜单
Menu menu2 = new Menu("权限管理", 2);
menu2.add(new MenuItem("页面访问",3));
menu2.add(new MenuItem("提交保存",3));
// 创建2级菜单
Menu menu3 = new Menu("角色管理", 2);
// 添加3级菜单
menu3.add(new MenuItem("页面访问",3));
menu3.add(new MenuItem("新增角色",3));
menu3.add(new MenuItem("修改角色",3));
// 添加2级菜单
rootMenu.add(menu1);
rootMenu.add(menu2);
rootMenu.add(menu3);
rootMenu.print();
}
}
分类和优点
在使用组合模式时,根据抽象构件类的定义形式,我们可将组合模式分为透明组合模式和安全组合模式。
- 透明组合模式:
透明组合模式中,抽象根节点角色中声明了所有用于管理成员对象的方法,比如在示例中,MenuComponent
声明了add
、remove
、getChile
方法,这样做法的好处是确保所有的构件类都有相同的接口,透明组合模式也是组合模式的标准形式。 - 安全组合模式:
在安全组合模式中,在抽象构件角色中没有声明任何用于管理成员对象的方法,而是在树枝节点Menu
类中声明并实现这些方法。安全组合模式的缺点是不够透明,因为叶子构件和容器构件具有不同的方法,且容器构件中那些用于管理成员对象的方法没有在抽象构件类中定义,因此客户端不能完全针对抽象编程,必须有区别地对待叶子构件和容器构件。
优点:
- 组合模式可以清楚地定义分层次地复杂对象,表示对象地全部或部分层次,它让客户端忽略了层次地差异,方便对整个层次结构进行控制。
- 客户端可以一致地使用一个组合结构或其中某个单个对象,不必关系处理的是单个对象还是组合对象,简化了客户端代码
- 在组合模式中增加新的树枝节点和叶子节点都很方便,无须对现有类库进行任何修改,符合“开闭原则”
- 组合模式为树形结构的面向对象实现,提供了一种灵活的解决方案,通过叶子节点和树枝节点的递归组合,可以形成复杂的树形结构,但对树形结构的控制却非常简单
在JDK中的使用
HashMap中使用了组合模式
public class Composite {
public static void main(String[] args) {
/**
* 说明:
* 1. Map/AbstractMap 就相当于抽象的构建(类似于MenuComponent)
* 2. HashMap 实现/继承了相关方法,相当于树枝节点(类似于Menu)
* 3. Node 是HashMap的静态内部类, 相当于菜单项类(类似于MenuItem)
* Node 中没有实现put,putAll等相关方法
*/
Map<Integer,String> hashMap = new HashMap<>();
hashMap.put(0,"东游记"); // 直接存放叶子节点(Node)
Map<Integer,String> map = new HashMap<>();
map.put(1,"西游记");
map.put(1,"红楼梦");
hashMap.putAll(map);
System.out.println(hashMap);
}
}
使用场景
组合模式正是应树形结构而生,所以组合模式的使用场景就是出现树形结构的地方。比如:文件目录显示,多级目录呈现等树形结构数据的操作
享元模式
概念
定义:
- 又称“蝇量模式”,运用共享技术有效地支持大量细粒度对象的复用。
- 常用于系统底层开发,解决系统的性能问题。像数据库连接池,里面都是创建好的连接对象,在这些连接对象中有我们需要的则直接拿来用,避免重新创建,如果没有我们需要的,则创建一个。
- 享元模式能够解决重复对象的内存浪费的问题,当系统中有大量相似对象,需要缓冲池时,不需总是创建新对象。直接在缓冲池里拿,降低了系统内存,同时提高效率。
- 享元模式就是池技术的重要实现方式
组成
享元(Flyweight)模式中存在以下两种状态:
- 内部状态:指对象共享出来的信息,存储在享元对象内部且不会随环境的改变而改变
- 外部状态:指随环境改变而改变的不可共享的部分。享元模式的实现要领就是区分应用中的这两种状态,并将外部状态外部化。
享元模式主要有以下几个角色:
- 抽象享元角色(Flyweight):通常是一个接口或抽象类,在抽象享元类中声明了具体享元类公共的方法,这些方法可以向外界提供享元对象的内部数据(内部状态),同时也可以通过这些方法来设置外部数据(外部状态)。
- 具体享元(Concrete Flyweight)角色:它实现了抽象享元类,称为享元对象;在具体享元类中内部状态提供了存储空间。通常我们可以结合单例模式来设计具体享元类,为每一个具体享元类提供唯一的享元对象。
- 非享元(Unsharable Flyweight)角色:并不是所有的抽象享元类的子类都需要被共享,不能被共享的子类可设计为非共享元类;当需要一个非共享具体享元类的对象时可以直接通过实例化创建。
- 享元工厂(Flyweight Factory)角色:负责创建和管理享元角色。当客户对象请求一个享元对象时,享元工厂检查系统中是否存在符合要求的享元对象,如果存在则提供给客户;如果不存在的话,则创建一个新的享元对象。
案例实现
【网站展示项目】
小型的外包项目,给客户A做一个产品展示网站,客户A的朋友感觉效果不错,也想要,但是要求时以新闻的形式发布,还有以博客的形式发布,以微信公众号的形式发布。
代码展示
// 网站抽象(抽象享元角色)
public abstract class WebSite {
public abstract void use(User user);
}
// 具体网站(具体享元角色)
public class ConcreteWebSite extends WebSite{
//内部状态
private String type = ""; // 网站发布的形式(类型)
// 构造器
public ConcreteWebSite(String type){
this.type = type;
}
@Override
public void use(User user) {
System.out.println("网站的发布形式为"+type+" "+user.getName()+"在使用");
}
}
// 非共享角色(外部状态)
public class User {
String name;
public User(String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
// 网站工厂类
public class WebSiteFactory {
//集合,充当池的作用
private HashMap<String,WebSite> pool = new HashMap<>();
// 根据网站的类型,返回一个网站,如果没有就创建一个网站,并放入池中
public WebSite getWebSiteCategory(String type){
if(!pool.containsKey(type)){
pool.put(type,new ConcreteWebSite(type));
}
return (WebSite)pool.get(type);
}
//获取网站分类的总数
public int getWebSiteCount(){
return pool.size();
}
}
测试:
public class WebSiteTest {
public static void main(String[] args) {
WebSiteFactory factory = new WebSiteFactory();
WebSite site = factory.getWebSiteCategory("新闻");
site.use(new User("tom"));
WebSite site2 = factory.getWebSiteCategory("新闻");
site2.use(new User("jack"));
WebSite site3 = factory.getWebSiteCategory("公众号");
site3.use(new User("rose"));
WebSite site4 = factory.getWebSiteCategory("公众号");
site4.use(new User("marry"));
System.out.println("当前池中的数量: "+factory.getWebSiteCount());
}
}
上面案例重点在于池化思想,故没有在工厂类加单例
优缺点和使用场景
优点
- 极大减少内存中相似或相同对象数量,节约系统资源,提供系统性能
- 享元模式中的外部状态相对独立,且不影响内部状态。
缺点 - 为了使对象可以共享,需要将享元对象的部分状态外部化,分离内部状态和外部状态,使程序逻辑复杂
使用场景 - 一个系统中有大量相同或相似的对象,造成内存的大量耗费
- 对象的大部分状态都可以外部化,可以将这些外部状态传入对象中
- 在使用享元模式时,需要维护一个存储享元对象的享元池,而这需要耗费一定的系统资源,因此,应当在需要多次重复使用享元对象时才值得使用享元模式。
在JDK源码中的使用
package com.ming.structure.flyweight.jdksrc;
/**
* @Author: mei_ming
* @DateTime: 2022/12/12 20:34
* @Description: Integer中的享元模式
*/
public class FlyWeightTest {
public static void main(String[] args) {
Integer x = Integer.valueOf(127);
Integer y = new Integer(127);
Integer z = Integer.valueOf(127);
Integer w = new Integer(127);
Integer v = 127;
System.out.println(x.equals(y)); // true
System.out.println(x == y); // false
System.out.println(x == z); // true
System.out.println(x == w); // false
System.out.println(y == w); // false
System.out.println(x == v); // true
/**
* public static Integer valueOf(int i) {
* if (i >= IntegerCache.low && i <= IntegerCache.high)
* return IntegerCache.cache[i + (-IntegerCache.low)];
* return new Integer(i);
* }
*
* private static class IntegerCache {
* static final int low = -128;
* static final int high;
* static final Integer cache[];
*
* static {
* // high value may be configured by property
* int h = 127;
* // ............
* }
* }
* 从上面部分源码可知,
* 1. 在valueOf方法中,先判断值是否在IntegerCache(-128~127) 中,
* 如果不在,就创建新的Integer,否则,就直接从缓存池返回
* 2. 这里使用到了享元模式
*/
}
}