一、代理模式
给某对象提供一个代理以控制对目标对象的访问。这时,访问对象不能直接引用目标对象,代理对象作为访问对象和目标对象之间的中介。
结构:
抽象主题类(Subject):通过接口或抽象类声明主题和代理对象实现的业务方法
真实主题类(Real Subject):实现类抽象主题中的具体业务,是代理对象所代表的真实对象,是最终要引用的对象。
代理类(Proxy):提供了与真实主题相同的接口,其内部含有对真实主题的引用,它可以访问、控制或扩展真实主题的功能。
静态代理
静态代理类在编译期就生成。
//抽象主题类
public interface SellTickets{
void sell();
}
// 真实主题类
public TrainStation implements SellTickets{
public void sell(){
sout("火车站卖票");
}
}
//代理类
public class ProxyPoint implements SellTickets{
//声明火车站类对象
private TranStation trainStation = new TranStation();
public void sell(){
sout("代售点收一点代理费");
trainStation.sell();
}
}
动态代理
动态代理在Java运行时动态生成。又分为JDK代理和CGLib代理两种。
JDK动态代理
/**
* 获取代理对象的工厂类
* 代理类也实现了对应的接口
*/
public class ProxyFactory {
// 声明目标对象(接口的实现类)
private TrainStation trainStation = new TrainStation();
// 返回代理对象
public Selltickets getProxyObject() {
/*
ClassLoader loader : 类加载器,用于加载代理类,可以通过目标对象获取类加载器
Class<?> interfaces : 代理类实现的接口的字节码对象
InvocationHandler h : 代理对象的调用处理程序
*/
Selltickets proxyObject = (Selltickets) Proxy.newProxyInstance(
trainStation.getClass().getClassLoader(),
trainStation.getClass().getInterfaces(),
new InvocationHandler() {
/*
Object proxy:代理对象,和proxyObject对象是同一个对象,在invoke方法中基本不用
Method method:对接口中的方法进行封装的method方法
Object[] args:调用方法的实际参数
*/
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
// System.out.println("invoke方法执行了");
System.out.println("代售点收取费用");
Object obj = method.invoke(trainStation, args);
return obj;
}
}
);
return proxyObject;
}
}
动态代理执行:
代理类($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.itheima.proxy.dynamic.jdk.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;
}
}
//代理工厂类
public class ProxyFactory {
private TrainStation station = new TrainStation();
public SellTickets getProxyObject() {
SellTickets sellTickets = (SellTickets) Proxy.newProxyInstance(station.getClass().getClassLoader(),
station.getClass().getInterfaces(),
new InvocationHandler() {
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
System.out.println("代理点收取一些服务费用(JDK动态代理方式)");
Object result = method.invoke(station, args);
return result;
}
});
return sellTickets;
}
}
//测试访问类
public class Client {
public static void main(String[] args) {
//获取代理对象
ProxyFactory factory = new ProxyFactory();
SellTickets proxyObject = factory.getProxyObject();
proxyObject.sell();
}
}
执行流程如下:
1、在测试类中通过代理对象sell()方法
2、根据多态的特性,执行的是代理类($Proxy0)中的sell()方法
3、代理类($Proxy0)中的sell()方法中又调用了InvocationHandler接口中的子实现类对象的invoke方法
4、invoke方法通过反射执行了真实对象所属类(TrainStation)中的sell()方法
Cglib动态代理
目标代理类
public class TrainStation{
public void sell() {
System.out.println("火车站销售车票");
}
}
代理类工厂
1.需要引入cglib依赖
2.实现MethodInterceptor是因为回调函数中的参数需要该接口的子类
3.cglib不能对声明为final的类或者方法进行代理,因为cglib原理是动态生成被代理类的子类。
public class ProxyFactory implements MethodInterceptor {
private TrainStation trainStation = new TrainStation();
public TrainStation getProxyObject() {
// 创建Enhancer对象,类似于JDKdialing中的Proxy类
Enhancer enhancer = new Enhancer();
// 设置父类的字节码对象
enhancer.setSuperclass(TrainStation.class);
// 设置回调函数
enhancer.setCallback(this);
// 创建代理对象
TrainStation proxyObject = (TrainStation) enhancer.create();
return proxyObject;
}
@Override
public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
System.out.println("代理点收取费用");
// 调用目标对象的方法
Object obj = method.invoke(trainStation, objects);
return obj;
}
}
JDK代理和cglib代理对比
JDK代理的效率高于cglib效率,所以只有没有接口时使用cglib代理,有接口时使用jdk代理。
动态代理和静态代理区别
动态代理与静态代理相比较,最大的好处是接口中声明的所有方法都被转移到调用处理器一个几种的方法中处理(例如cglib中的intercept和jdk的invoke)。
这样,在接口方法数量比较多的时候,我们可以进行灵活处理,而不需要像静态代理那样每一个方法进行中转。
如果接口每增加一个方法,静态代理模式除了所有实现类需要实现这个方法外,所有代理类也需要实现此方法。增加了代码维护的复杂度。而静态代理不会出现该问题。
使用场景
1)远程代理(RPC底层实现)
本地服务通过网络请求远程服务,为了实现本地到远程的通信,我们需要实现网络通信,处理其中可能的异常。为良好的代码设计和可维护性,我们将网络部分隐藏起来,只暴露给本地服务一个接口,通过该接口即可访问远程服务提供分功能,而不必过多关心通信部分的细节。
2)防火墙代理
当你将浏览器配置成使用代理功能时,防火墙就将你的浏览器的请求转给互联网。当互联网返回响应时,代理服务器再把它转给你的浏览器。
3)保护代理
控制对一个对象的访问,如果需要,可以给不同的用户提供不同级别的使用权限。
二、适配器模式
将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
主要角色:
目标接口(Target):
当前系统业务所期待的接口,它可以是抽象类或接口。
适配者类(Adaptee):
它是被访问和适配的显存组件库中的组件接口。
适配器类(Adapter):
它是一个转换器,通过继承(类适配器)或引用适配者的对象(对象适配器),把适配者接口转换成目标接口,让客户按目标接口的格式访问适配者。
类适配器模式
实现方式:定义一个适配器类来实现当前系统的业务接口,同时又继承先有组件库中已经存在的组件。
// TFCard是需要被代理的类,SDCard是已有的类
public class SDAdapterTF extends TFCardImpl implements SDCard{
@Override
public String readSd() {
System.out.println("TFCard read");
return readTf();
}
@Override
public void writeSd(String msg) {
System.out.println("TFCard writer"+msg);
writeTf(msg);
}
}
类适配器模式违背了合成复用原则。类适配器是客户类有一个接口规范的情况下可用,如果当前系统的业务直接是一个类,而不是接口,则不可用。
对象适配器模式
我们有一个目标接口Target,其中包含方法request()。
还有一个适配者类Adaptee,其中包含方法specificRequest()。
我们想要使用Adaptee类的specificRequest()方法来实现Target接口的request()方法。
// 目标接口
// 当前业务所期待的接口
interface Target {
void request();
}
// 适配者类
// 被访问和适配的组件接口
class Adaptee {
void specificRequest() {
System.out.println("Adaptee specific request");
}
}
// 对象适配器类
class Adapter implements Target {
private Adaptee adaptee;
Adapter(Adaptee adaptee) {
this.adaptee = adaptee;
}
@Override
public void request() {
adaptee.specificRequest();
}
}
// 测试类
public class Test {
public static void main(String[] args) {
Adaptee adaptee = new Adaptee();
Target target = new Adapter(adaptee);
target.request(); // 输出:Adaptee specific request
}
}
注意:还有一个适配器模式是接口适配器模式,当不希望实现一个接口中所有的方法时,可以创建一个抽象类Adapter,实现所有方法,而此时我们只需要继承该抽象类即可。
应用场景:
1)以前开发的系统存在满足新系统功能需求的类,但其接口同新系统的接口不一致。
2)使用第三方提供的组件,但组件接口定义和自己要求的接口定义不同。
JDK源码解析
Reader(字符流)、InputStream(字节流)的适配使用的是InputStreamReader。
InputStreamReader继承自java.io包中的Reader,对他中的抽象的未实现的方法给出实现。如:
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(StreamDecoder类对象),在Sun的JDK实现中,实际的方法实现是对sun.nio.cs.StreamDecoder类的同名方法的调用封装。类结构图如下:
从上图可以看出:
- InputStreamReader是对同样实现了Reader的StreamDecoder的封装。
- StreamDecoder不是Java SE API中的内容,是Sun JDK给出的自身实现。但我们知道他们对构造方法中的字节流类(InputStream)进行封装,并通过该类进行了字节流和字符流之间的解码转换。
结论:
从表层来看,InputStreamReader做了InputStream字节流类到Reader字符流之间的转换。而从如上Sun JDK中的实现类关系结构中可以看出,是StreamDecoder的设计实现在实际上采用了适配器模式。