JAVA设计模式-装饰者模式

一.概念

装饰器模式(Decorator Pattern)，动态地给一个对象添加一些额外的职责，就增加功能来说，装饰器模式比生成子类更灵活。 —-《大话设计模式》

允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。

这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。

动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。

二.角色

Component（抽象构件）：给出一个抽象接口，装饰器模式中公共方法的类，在装饰器模式结构图的顶层，以规范准备接收附加责任的对象。
ConcreteComponent（具体构件）：是要动态扩展的对象，转换器模式中具体的被装饰的类，它继承自Component。
Decorator（装饰器）：持有一个构件(Component)对象的实例，它是装饰器模式中的核心对象，所有具体装饰器对象的父类，完成装饰器的部分职能。可以只对被装饰的对象进行一些简单的包裹，也可包含对Component中方法的实现。
ConcreteDecorator（具体装饰）：完成具体的装饰功能。装饰功能的实现是通过调用被装饰对象对应的方法，加上装饰对象自身的方法。这是装饰器模式动机中的添加额外功能的关键。

三.优缺点

1.优点

装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。
装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”或者除掉一个“装饰”，继承关系是静态的，它在系统运行前就决定了；
通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合；
装饰者类可以在被装饰者的行为前面或后面加上自己的行为，甚至取代被装饰者的行为，达到特定的目的；
装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型

2.缺点

多层装饰比较复杂。
由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。

四.适用场景

运行时，你需要动态地为对象增加额外职责时；
当你需要一个能够代替子类的类，借助它提供额外方法时。
在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责；
处理那些可以撤销的职责；
当不能采用生成子类的方式进行扩充时。

五.装饰器模式与适配器模式的比较

共同点：都拥有一个目标对象。装饰器通过包装一个装饰对象来扩展其功能，而又不改变其接口，这实际上是基于对象的适配器模式的一种变种。
不同点：适配器模式需要实现另外一个接口，而装饰器模式必须实现该对象的接口。适配器模式主要是为了接口的转换，而装饰者模式关注的是通过组合来动态的为被装饰者注入新的功能或行为(即所谓的责任)。

六.实现

假设我去买咖啡，首先服务员给我冲了一杯原味咖啡，我希望服务员给我加些牛奶和白糖混合入原味咖啡中。使用装饰器模式就可以解决这个问题。

咖啡接口

定义了获取花费和配料的接口。

/*** 咖啡接口*/
public interface Coffee {/*** 获取价格* @return*/public float getPrice();/*** 获取咖啡* @return*/public String getCoffee();
}

原味咖啡

实现Coffe接口，花费1元，配料中，只有咖啡

/*** 原味咖啡类*/
public class OriginalCoffee implements Coffee {@Overridepublic float getPrice() {return 1;}@Overridepublic String getCoffee() {return "原味咖啡";}
}

装饰器类

咖啡对象的装饰器类，同样实现Coffee接口，定义一个Coffe对象的引用，在构造器中进行初始化。并且将getPrice（）和getCoffee()方法转发给被装饰对象。

/*** 咖啡的"装饰器"，可以给咖啡添加各种"配料"* 该类是一个抽象类需要具体子类来实现*/
public class DecoratorAbstractCoffee implements Coffee {/*** 具体咖啡的接口*/protected final  Coffee coffee;/*** 构造方法，初始化咖啡对象的引用* @param coffee*/public DecoratorAbstractCoffee(Coffee coffee) {this.coffee = coffee;}/*** 获取价格，装饰器父类中直接转发"请求"至引用对象* @return*/@Overridepublic float getPrice() {return coffee.getPrice();}/*** 获取咖啡，装饰器父类中直接转发"请求"至引用对象* @return*/@Overridepublic String getCoffee() {return coffee.getCoffee();}
}

具体的装饰器类

具体的装饰器类，负责往咖啡中“添加”牛奶，注意看getPrice（）方法和getCoffee()方法，可以在转发请求之前或者之后，增加功能。如果是代理模式，这里的结构就有所不同，通常代理模式根据运行时的条件来判断是否转发请求。

/*** 混合牛奶到蜂蜜中*/
public class CreamCoffee extends DecoratorAbstractCoffee {private float price = (float) 0.5;/*** 调用父类的构造方法* @param coffee*/public CreamCoffee(Coffee coffee) {super(coffee);}/*** 增加配料需要加钱* @return*/@Overridepublic float getPrice() {return coffee.getPrice()+price;}/*** 对咖啡进行加工* @return*/@Overridepublic String getCoffee() {return coffee.getCoffee()+"；添加牛奶";}
}

添加糖

另一个具体装饰器类，用来给咖啡加蜂蜜，一样的逻辑。

class HoneyCoffee extends DecoratorAbstractCoffee {private float price = (float) 1.4;public HoneyCoffee(Coffee coffee) {super(coffee);}@Overridepublic float getPrice() {return coffee.getPrice()+price;}@Overridepublic String getCoffee() {return coffee.getCoffee()+"；添加蜂蜜";}
}

客户端使用

public class DecoratorMain {public static void main(String[] args) {//是不是很像 javaIO中的 stream流Coffee coffee = new CreamCoffee(new HoneyCoffee(new OriginalCoffee()));System.out.println(coffee.getCoffee());System.out.println(coffee.getPrice());}
}

七.装饰者模式在Spring Boot中的应用

装饰者模式在Spring Boot中有着广泛的应用，主要用于动态地扩展和改变对象的行为和状态。以下是装饰者模式在Spring Boot中的一些常见应用：

自定义异常处理：Spring Boot允许你通过装饰者模式来为你的控制器添加自定义的异常处理。你可以创建一个异常处理器，然后通过装饰者模式将其添加到Spring MVC的异常处理器链中。这样，当控制器抛出异常时，你的自定义处理器就会被调用。
安全性控制：Spring Security是Spring Boot中用于安全性控制的一个库。它使用了装饰者模式来动态地为请求添加安全性检查。你可以创建一个自定义的安全性过滤器，然后将其添加到Spring Security的过滤器链中，以实现自定义的安全性控制。
响应式编程：Spring WebFlux是Spring Boot中的响应式编程框架。它使用了装饰者模式来动态地为服务器端点添加响应式处理。你可以创建一个自定义的响应式处理器，然后将其添加到WebFlux的处理器链中，以实现自定义的响应式处理逻辑。
拦截器：Spring MVC允许你使用拦截器来在控制器处理请求之前或之后执行一些操作。拦截器实际上就是使用了装饰者模式。你可以创建一个自定义的拦截器，然后将其添加到Spring MVC的拦截器链中，以实现自定义的请求拦截和处理。

这些应用只是装饰者模式在Spring Boot中的一部分。事实上，只要你需要动态地扩展和改变对象的行为和状态，装饰者模式就可能是一个好的解决方案。