设计模式之--装饰者模式

认识装饰者模式

装饰者模式的定义：

不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。

代码开发中遵循开放-关闭原则，即类应该对扩展开放,对修改关闭。

举个栗子：假设我们开一间餐厅，就卖黄焖鸡米饭,黄焖鸡有大份、中份、小份，还可以加各种食材，比如香菇、宽粉、肥牛等等，还有各种饮料,加入我们为每一种品类都写一个类,并计算价格,类的数量就会非常多也就是造成类爆炸,另外就假如我的某各品类里面加入一种品类，那么就会修改之前写的那些类，违背了开闭原则。这个时候我们使用装饰者模式更合理。

装饰者模式的组件： 如下图

1.Component（被装饰对象的基类,通常为抽象类）

定义一个对象接口，可以给这些对象动态地添加职责。

2.ConcreteComponent（具体被装饰对象）

定义一个对象，可以给这个对象添加一些职责。

3.Decorator（装饰者抽象类）

  维持一个指向Component实例的引用，并定义一个与Component接口一致的接口。

4.ConcreteDecorator（具体装饰者）

  具体的装饰对象，给内部持有的具体被装饰对象，增加具体的职责

在上面的栗子中,黄焖鸡原料就可以是被装饰者对象ConcreteComponent,各种添加的食材就可以作为具体装饰者。不过今天我们不用上面的栗子演示，而是结合工作中具体的遇到的业务讲解。

业务实战

业务背景

笔者的公司正在做信息化转型,开始使用前后端分离架构，为了统一架构和方便开发,笔者为后端服务做了一个客户端SSO-Client,开发者引入这个Jar就可以完美接入企业的SSO认证,没有代码侵入。但是好景不长，部门其他团队在启用新项目时说我的客户端无法满足需求,深入了解才知道，原来部门的其他系统比如ECP/WMS,还有自己独立登录系统,他们可能引入外部客户（比如供应商、渠道），而公司之前的SSO服务只是管理到了公司员工,所以在此基础上,衍生出了新的需求。

1）项目除了接入SSO，还要接入第三方（可能是现有）的登录系统。
2）项目还需要有切换身份。

解决方案：

SSO-client兼容上述两种情况。通过客户端自定义配置的方式实现。1) 2)可能使用不同的Cookie实现,同时支持url和自定义实现类

最初的代码实现：

(1)定义SSOProperties：

 @ConfigurationProperties("spring.rj.sso")
public class SSOProperties {
    /**
     * 认证过滤器开关，默认为on.
     */
    private String flag;
    /**
     * 认证过滤器跳过的URI,多个用逗