자, 오늘은 디자인 패턴에 대해 装饰器模式나누어보겠습니다. 적절한 인생 이야기와 실제 프로젝트 시나리오를 사용하여 디자인 패턴에 대해 이야기하고 마지막으로 디자인 패턴을 한 문장으로 요약합니다.
옛말처럼: 사람은 옷을 의지하고 말은 안장을 의지합니다. 먼저 이 문장의 배경을 숙지해 봅시다:
사람은 옷에 의지하고, 말은 안장에 의지하고, 개는 종소리를 들고 달린다. 이 말은 심자진의 『왕호각』 제10장에 나오는 것이다. 금옷에 대하여 "사람은 옷을 입는데, 몸단장도 매우 중요하다." "깨어나는 말" 제1권: 정의로운 결혼을 위해 경쟁하는 현 행정관의 두 고아: "부처님은 금옷을 입으셨고, 사람은 금빛 옷을 입는다." 옷을 입고, 세상의 많은 사람들은 눈이 얕고, 뼈만 있고, 어른들은 옷에 의지하고 말은 안장에 의지합니다.
이 고전적인 이야기는 디자인 패턴인 데코레이터 패턴을 생각나게 합니다.
데코레이터 패턴이란 무엇인가요? Lao Tian의 이야기를 천천히 들어보세요.
데코레이터 패턴(Decorator Pattern)은 래퍼 패턴(Wrapper Pattern)이라고도 하는데, 원래 객체를 변경하지 않고 객체에 일부 요소를 동적으로 추가하는 것을 말합니다. 기능 추가 측면에서 데코레이터 패턴은 하위 클래스를 생성하는 것보다 더 유연하며 구조적 디자인 패턴입니다.
영어:
동일한 인터페이스를 유지하면서 객체에 추가 책임을 추가합니다. 데코레이터는 객체에 기능을 확장하기 위한 하위 클래스화에 대한 유연한 대안을 제공합니다. 따라서 데코레이터 패턴의 핵심은 기능 확장이다. 데코레이터 패턴을 사용하여 클래스의 기능을 투명하고 동적으로 확장합니다.
//抽象组件
public abstract class Component {
public abstract void operation();
}
//具体组件
public class ConcreteComponent extends Component {
@Override
public void operation() {
System.out.println("ConcreteComponent operation");
}
}
//装饰器抽象
public abstract class Decorator extends Component {
protected Component component;
public Decorator(Component component) {
this.component = component;
}
@Override
public void operation() {
component.operation();
}
}
//具体装饰器
public class ConcreteDecorator extends Decorator {
public ConcreteDecorator(Component component) {
super(component);
}
@Override
public void operation() {
System.out.println("开始前搞点事");
super.operation();
System.out.println("结束后搞点事");
}
}
//测试
public class Client {
public static void main(String[] args) {
Component component = new ConcreteDecorator(new ConcreteComponent());
component.operation();
}
}开始前搞点事 ConcreteComponent operation 结束后搞点事
装饰器模式角色分配符合设计模式的里氏替换原则、依赖倒置原则，从而使得其具备很强的扩展性，最终满足开闭原则。
装饰器模式的实现原理是，让装饰器实现与被装饰类（例如ConcreteComponent）相同的接口（例如Component），使得装饰器与被扩展类类型一致，并在构造函数中传入该接口对象，然后在实现这个接口的被包装类对象的现有功能上添加新功能。由于装饰器与被包装类属于同一类型（均为Component），且构造函数的参数为其实现接口类（Component），因此装饰器模式具备嵌套扩展功能，这样就能使用装饰器模式一层一层地对底层被包装类进行功能扩展了。
在实际开发中，都会存在系统与系统之间的调用，假如说我们现在有个支付功能，现在一切都是没问题的，但是 我们此时需要对发起支付前的请求参数和支付后的相应参数。进行统一处理，原功能不变，只是在原功能上做了一点扩展（增强）。
老功能代码如下：
/**
* @author 田先生
* @date 2021-06-02
*
* 欢迎关注公众号：java后端技术全栈
*/
public interface IOrderPayService {
String payment(Long orderId, BigDecimal amount);
}
public class OrderPayServiceImpl implements IOrderPayService {
@Override
public String payment(Long orderId, BigDecimal amount) {
//先调用余额查询是否足够
System.out.println("发起支付，订单号：" + orderId + "， 支付金额：" + amount.toString());
//调用支付系统
String result = "订单id=" + orderId + "支付完成";
System.out.println("支付结果：" + result);
return result;
}
}
public class OrderClient {
public static void main(String[] args) {
IOrderPayService orderPayService = new OrderPayServiceImpl();
orderPayService.payment(10001L,new BigDecimal("5000"));
}
}运行输出：
发起支付，订单号：10001， 支付金额：5000 支付结果：订单id=10001支付完成
新需求，需要把这些请求参数和相应结果进行单独搜集处理，此时为了不影响原有功能，于是我们可以对其进行功能增强。
/**
* @author 田先生
* @date 2021-06-02
*
* 欢迎关注公众号：java后端技术全栈
*/
public class OrderPayDecorator implements IOrderPayService {
private IOrderPayService orderPayService;
public OrderPayDecorator(IOrderPayService orderPayService) {
this.orderPayService = orderPayService;
}
@Override
public String payment(Long orderId, BigDecimal amount) {
System.out.println("把这个订单信息（发起支付）" + "订单id=" + orderId + "支付金额=" + amount.toString() + " 【发送给MQ】");
String result = orderPayService.payment(orderId, amount);
System.out.println("把订单支付结果信息" + result + " 【发送给MQ】");
return result;
}
}
public class OrderClient {
public static void main(String[] args) {
IOrderPayService orderPayService =new OrderPayDecorator(new OrderPayServiceImpl());
orderPayService.payment(10001L,new BigDecimal("5000"));
}
}运行输出：
把这个订单信息（发起支付）订单id=10001支付金额=5000 【发送给MQ】 发起支付，订单号：10001， 支付金额：5000 支付结果：订单id=10001支付完成 把订单支付结果信息订单id=10001支付完成 【发送给MQ】
整个过程，大家有没有发现，我们并没动原有的代码，仅仅只是做了功能增强。
装饰器模式在新项目中基本上不会用到，通常都是在老项目中使用，因为已有的功能不变，只是做了一些功能增强。
装饰器设计模式在JDK源码、Spring源码以及Mybatis源码中都有。
装饰器模式比较经典的应用就是 JDK 中的 java.io 包下，InputStream、OuputStream、Reader、Writer 及它们的子类。
以 InputStream 为例
UML图
DataInputStream 中构造器入参便是自己的父类（InputStream）。
如果希望提供一个可以读取文件 + 可缓存的字节流，使用继承方式，就需要派生 FileBufferedInputStream；
如果希望提供一个可以读取文件 + 直接读取基本类型的字节流，使用继承方式，就需要派生 FileDataInputStream。
字节流功能的增强还包括支持管道 pipe、字节数组 bytearray、字节对象 object、字节流字符流的转换 等维度，如果用继承方式，那类的层级与种类会多到爆炸。
为了解决问题，这边就使用了装饰器模式。
在Spring中，我们可以尝试理解一下TransactionAwareCacheDecorator类，这个类主要用来处理事务缓存，代码如下。
public class TransactionAwareCacheDecorator implements Cache {
private final Cache targetCache;
//构造方法入参类型为自己的父类（接口类型）
public TransactionAwareCacheDecorator(Cache targetCache) {
Assert.notNull(targetCache, "Target Cache must not be null");
this.targetCache = targetCache;
}
public Cache getTargetCache() {
return this.targetCache;
}
//...
}TransactionAwareCacheDecorator就是对Cache的一个包装，因此，这里也是使用了装饰器模式。
MyBatis中关于Cache和CachingExecutor接口的实现类也使用了装饰者设计模式。Executor是MyBatis执行器，是MyBatis 调度的核心，负责SQL语句的生成和查询缓存的维护；CachingExecutor是一个Executor的装饰器，给一个Executor增加了缓存的功能。此时可以看做是对Executor类的一个增强，故使用装饰器模式是合适的。
在CachingExecutor 中
public class CachingExecutor implements Executor {
//持有组件对象
private Executor delegate;
private TransactionalCacheManager tcm = new TransactionalCacheManager();
//构造方法，传入组件对象
public CachingExecutor(Executor delegate) {
this.delegate = delegate;
delegate.setExecutorWrapper(this);
}
@Override
public int update(MappedStatement ms, Object parameterObject) throws SQLException {
//转发请求给组件对象，可以在转发前后执行一些附加动作
flushCacheIfRequired(ms);
return delegate.update(ms, parameterObject);
}
//...
}看完装饰器模式后，你是否有感觉，装饰器模式和代理模式非常的相像，下面我们就来做个对比。
1.装饰器模式可以理解为一种特殊的代理模式。
2.装饰器模式强调自身的功能扩展，透明的扩展（即用户想增强什么功能就增强什么功能），可动态定制的扩展。
3.代理模式强调的是代理过程的控制。
优点
缺点
위 내용은 3년간의 작업 필수 데코레이터 패턴의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
