23种设计模式
结构型模式
适配器模式
基本介绍
- 适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表示,主要目的是兼容性,让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)。
- 适配器模式属于结构型模式。
- 主要分为三类:类适配器模式、对象适配器模式、接口适配器模式。
适配器模式工作原理
- 适配器模式将一个类的接口转换成另一种接口让原本接口不兼容的类可以兼容,从用户的角度看不到被适配者,是解耦的。
- 用户调用适配器转化出来的目标接口方法,适配器再调用被适配者的相关接口方法。
- 用户收到反馈结果,感觉只是和目标接口交互,如图:

类适配器模式
- 基本介绍:Adapter类,通过继承 src类,实现 dst 类接口,完成 src 到 dst 的适配。
- 应用实例:以生活中充电器的例子来讲解适配器,充电器本身相当于Adapter,220V交流电相当于src (即被适配者),我们的目dst(即 目标)是5V直流电。
- UML类图:

- 代码实现:
/**
* 适配器模式
*/
public class AdapterCase01 {
public static void main(String[] args) {
new Phone().charging(new ClassVoltageAdapter());
}
}
/**
* 被适配的类
*/
class Voltage220V {
public int output220V() {
int src = 220;
System.out.println("电压" + src + "V");
return src;
}
}
/**
* 适配接口
*/
interface IVoltage5V {
int output5V();
}
/**
* 手机
*/
class Phone {
void charging(IVoltage5V voltage5V) {
int output = voltage5V.output5V();
if (output == 5) {
System.out.println("电压为5V,可以充电");
} else if (output > 5) {
System.out.println("电压大于5V,不可以充电");
}
}
}
/**
* 类适配器
*/
class ClassVoltageAdapter extends Voltage220V implements IVoltage5V {
@Override
public int output5V() {
System.out.println("----类适配器----");
int srcV = output220V();
int dstV = srcV / 44;
return dstV;
}
}
- Java是单继承机制,所以类适配器需要继承src类这一点算是一个缺点,因为这要求dst必须是接口,有一定局限性。
- src类的方法在Adapter中都会暴露出来,也增加了使用的成本。
- 由于其继承了src类,所以它可以根据需求重写src类的方法,使得Adapter的灵活性增强了。
对象适配器模式
- 基本思路和类的适配器模式相同,只是将Adapter类作修改,不是继承src类,而是持有src类的实例,以解决兼容性的问题。 即持有 src类,实现 dst 类接口,完成src到dst的适配。
- 根据“合成复用原则”,在系统中尽量使用关联关系来替代继承关系。
- 对象适配器模式是适配器模式常用的一种。
- UML类图:

- 代码实现:
/**
* 对象适配器
*/
class ObjectVoltageAdapter implements IVoltage5V {
private Voltage220V voltage220V;
ObjectVoltageAdapter(Voltage220V voltage220V) {
this.voltage220V = voltage220V;
}
@Override
public int output5V() {
System.out.println("----对象适配器----");
int srcV = voltage220V.output220V();
int dstV = srcV / 44;
return dstV;
}
}
- 对象适配器和类适配器其实算是同一种思想,只不过实现方式不同。根据合成复用原则,使用组合替代继承, 所以它解决了类适配器必须继承src的局限性问题,也不再要求dst必须是接口。
- 使用成本更低,更灵活。
接口适配器模式
- 一些书籍称适配器模式为(Default Adapter Pattern)或缺省适配器模式。
- 当不需要全部实现接口提供的方法时,可先设计一个抽象类实现接口,并为该接口中每个方法提供一个默认实现(空方法),那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求。
- 适用于一个接口不想使用其所有的方法的情况。
- UML类图:

- 代码实现:
public class AdapterCase02 {
public static void main(String[] args) {
AbstractAadpter adpter = new AbstractAadpter() {
@Override
public void m1() {
System.out.println("m1");
}
};
adpter.m1();
}
}
interface InterfaceA {
void m1();
void m2();
void m3();
void m4();
}
abstract class AbstractAadpter implements InterfaceA {
@Override public void m1() {
}
@Override public void m2() {
}
@Override public void m3() {
}
@Override public void m4() {
}
}
适配器模式在SpringMVC框架应用的源码分析
- SpringMvc中的HandlerAdapter,就使用了适配器模式。
- 可以看到处理器的类型不同,有多重实现方式,那么调用方式就不是确定的,如果需要直接调用 Controller 方法,需要调用的时候就得不断是使用 if else 来进行判断是哪一种子类然后执行。那么如果后面要扩展 Controller,得修改原来的代码,这样违背了 OCP 原则。

- Spring定义了一个适配接口,使得每一种Controller有一种对应的适配器实现类。
- 适配器代替controller执行相应的方法。
- 扩展Controller 时,只需要增加一个适配器类就完成了SpringMVC的扩展了,这就是设计模式的力量。
- 动手写SpringMVC通过适配器设计模式获取到对应的Controller的源码:
- UML类图:

- 代码实现:
// 处理器
public interface Handler {
void doHandle();
}
class SimpleHandler implements Handler {
@Override
public void doHandle() {
System.out.println("SimpleHandler.doHandle() ...");
}
}
class HttpHandler implements Handler {
@Override
public void doHandle() {
System.out.println("HttpHandler.doHandle() ...");
}
}
class AnnotationHandler implements Handler {
@Override
public void doHandle() {
System.out.println("AnnotationHandler.doHandle() ...");
}
}
// 处理器适配器
public interface HandlerAdapter {
boolean support(Handler handler);
void handle(Handler handler);
}
class SimpleHandlerAdapter implements HandlerAdapter {
@Override
public boolean support(Handler handler) {
return handler instanceof SimpleHandler;
}
@Override
public void handle(Handler handler) {
handler.doHandle();
}
}
class HttpHandlerAdapter implements HandlerAdapter {
@Override
public boolean support(Handler handler) {
return handler instanceof HttpHandler;
}
@Override
public void handle(Handler handler) {
handler.doHandle();
}
}
class AnnotationHandlerAdapter implements HandlerAdapter {
@Override
public boolean support(Handler handler) {
return handler instanceof AnnotationHandler;
}
@Override
public void handle(Handler handler) {
handler.doHandle();
}
}
// 分派
public class DispatchServlet {
private static List<HandlerAdapter> handlerAdapters = new ArrayList<>();
public DispatchServlet() {
handlerAdapters.add(new SimpleHandlerAdapter());
handlerAdapters.add(new HttpHandlerAdapter());
handlerAdapters.add(new AnnotationHandlerAdapter());
}
public void doDispatch() {
HttpHandler handler = new HttpHandler();
HandlerAdapter adapter = getHandler(handler);
if (adapter != null) {
adapter.handle(handler);
}
}
private HandlerAdapter getHandler(Handler handler) {
for (HandlerAdapter adapter : handlerAdapters) {
if (adapter.support(handler)) {
return adapter;
}
}
return null;
}
public static void main(String[] args) {
new DispatchServlet().doDispatch();
}
}
适配器模式的注意事项和细节
- 三种命名方式,是根据 src是以怎样的形式给到Adapter(在Adapter里的形式)来命名的。
- 类适配器:以类给到,在Adapter里,就是将src当做类,继承。
- 对象适配器:以对象给到,在Adapter里,将src作为一个对象,持有。
- 接口适配器:以接口给到,在Adapter里,将src作为一个接口,实现。
- Adapter模式最大的作用还是将原本不兼容的接口融合在一起工作。
桥接模式
手机操作问题
现在对不同手机类型的不同品牌实现操作编程(比如:开机、关机、上网,打电话等),如图:

传统方案解决手机操作问题

- 扩展性问题(类爆炸):如果我们再增加手机的样式(旋转式),就需要增加各个品牌手机的类,同样如果我们增加一个手机品牌,也要在各个手机样式类下增加。
- 违反了单一职责原则,当我们增加手机样式时,要同时增加所有品牌的手机,这样增加了代码维护成本。
- 解决方案-使用桥接模式。
桥接模式(Bridge)-基本介绍
- 桥接模式(Bridge模式)是指:将实现与抽象放在两个不同的类层次中,使两个层次可以独立改变,是一种结构型设计模式。
- Bridge模式基于类的最小设计原则,通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来,从而可以保持各部分的独立性以及应对他们的功能扩展。
- UML原理类图:

* 抽象类(Abstraction):维护了Implementor,及其实现子类,两者是聚合关系,Abstraction充当桥接类
* RefinedAbstraction:是Abstraction抽象类的实现子类
* Implementor:是行为实现类的接口
* ConcreteImplementorA、ConcreteImplementorB:是行为的具体实现类
- 代码实现:
public class BridgeCase01 {
public static void main(String[] args) {
Phone foldedXiaoMi = new FoldedPhone(new XiaoMi());
foldedXiaoMi.open();
foldedXiaoMi.close();
foldedXiaoMi.call();
System.out.println("===============");
Phone foldedViVo = new FoldedPhone(new ViVo());
foldedViVo.open(

本文深入解析23种设计模式,包括适配器模式、桥接模式、装饰器模式、组合模式、外观模式、享元模式和代理模式。通过具体案例阐述每种模式的原理、应用场景及优缺点。

1913

被折叠的 条评论
为什么被折叠?



