前言：
两个本想描述一样的意思的词，只因一字只差就让人觉得一个是好牛，一个好搞笑。往往我们去开发编程写代码时也经常将一些不恰当的用法用于业务需求实现中，但却不能意识到。一方面是由于编码不多缺少较大型项目的实践，另一方面是不思进取的总在以完成需求为目标缺少精益求精的工匠精神。

初看上图感觉装饰器模式有点像俄罗斯套娃、某众汽车🚕，而装饰器的核心就是在不改原有类的基础上给类新增功能。不改变原有类，可能有的小伙伴会想到继承、AOP切面，当然这些方式都可以实现，但是使用装饰器模式会是另外一种思路更为灵活，可以避免继承导致的子类过多，也可以避免AOP带来的复杂性。

这里模拟的是spring中的类：HandlerInterceptor，实现接口功能SsoInterceptor模拟的单点登录拦截服务。
模拟Spring的HandlerInterceptor

package oom.lm.design;

public interface HandlerInterceptor {

    boolean preHandle(String request, String response, Object handler);

}

模拟单点登录功能

package oom.lm.design;

public class SsoInterceptor implements HandlerInterceptor{

    
    @Override
    public boolean preHandle(String request, String response, Object handler) {
        // 模拟获取cookie
        String ticket = request.substring(1, 8);
        // 模拟校验
        return ticket.equals("success");
    }

}

里的模拟实现非常简单只是截取字符串，实际使用需要从HttpServletRequest request对象中获取cookie信息，解析ticket值做校验
用一坨坨代码实现
继承类的实现方式也是一个比较通用的方式，通过继承后重写方法，并发将自己的逻辑覆盖进去。如果是一些简单的场景且不需要不断维护和扩展的，此类实现并不会有什么，也不会导致子类过多。

package oom.lm.design;

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class LoginSsoDecorator extends SsoInterceptor {

    private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();

    static {
        authMap.put("huahua", "queryUserInfo");
        authMap.put("doudou", "queryUserInfo");
    }

    @Override
    public boolean preHandle(String request, String response, Object handler) {

        // 模拟获取cookie
        String ticket = request.substring(1, 8);
        // 模拟校验
        boolean success = ticket.equals("success");

        if (!success){
            return false;
        }

        String userId = request.substring(9);
        String method = authMap.get(userId);

        // 模拟方法校验
        return "queryUserInfo".equals(method);
    }

}

以上这部分通过继承重写方法，将个人可访问哪些方法的功能添加到方法中。
测试验证

package oom.lm.design.test;

import oom.lm.design.LoginSsoDecorator;
import org.junit.Test;

public class ApiTest {

    @Test
    public void test_LoginSsoDecorator() {
        LoginSsoDecorator ssoDecorator = new LoginSsoDecorator();
        String request = "1successhuahua";
        boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
        System.out.println("登录校验：" + request + (success ? " 放行" : " 拦截"));
    }

}

装饰器模式重构代码
装饰器主要解决的是直接继承下因功能的不断横向扩展导致子类膨胀的问题，而是用装饰器模式后就会比直接继承显得更加灵活同时这样也就不再需要考虑子类的维护。
1：抽象构件角色(Component) - 定义抽象接口
2：具体构件角色(ConcreteComponent) - 实现抽象接口，可以是一组
3：装饰角色(Decorator) - 定义抽象类并继承接口中的方法，保证一致性
4：具体装饰角色(ConcreteDecorator) - 扩展装饰具体的实现逻辑

装饰器模式模型结构

抽象类装饰角色

package oom.lm.design;

public abstract class SsoDecorator implements HandlerInterceptor {

    private HandlerInterceptor handlerInterceptor;

    private SsoDecorator(){}

    public SsoDecorator(HandlerInterceptor handlerInterceptor) {
        this.handlerInterceptor = handlerInterceptor;
    }

    @Override
    public boolean preHandle(String request, String response, Object handler) {
        return handlerInterceptor.preHandle(request, response, handler);
    }

}

在装饰类中有三个重点的地方是：1)继承了处理接口、2)提供了构造函数、3)覆盖了方法preHandle。
装饰角色逻辑实现

package oom.lm.design;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class LoginSsoDecorator extends SsoDecorator {

    private Logger logger = LoggerFactory.getLogger(LoginSsoDecorator.class);

    private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();

    static {
        authMap.put("huahua", "queryUserInfo");
        authMap.put("doudou", "queryUserInfo");
    }

    public LoginSsoDecorator(HandlerInterceptor handlerInterceptor) {
        super(handlerInterceptor);
    }

    @Override
    public boolean preHandle(String request, String response, Object handler) {
        boolean success = super.preHandle(request, response, handler);
        if (!success) return false;
        String userId = request.substring(8);
        String method = authMap.get(userId);
        logger.info("模拟单点登录方法访问拦截校验：{} {}", userId, method);
        // 模拟方法校验
        return "queryUserInfo".equals(method);
    }
}

在具体的装饰类实现中，继承了装饰类SsoDecorator，那么现在就可以扩展方法；preHandle
测试验证

package oom.lm.design.test;

import oom.lm.design.LoginSsoDecorator;
import oom.lm.design.SsoInterceptor;
import org.junit.Test;

public class ApiTest {

    @Test
    public void test_LoginSsoDecorator() {
        LoginSsoDecorator ssoDecorator = new LoginSsoDecorator(new SsoInterceptor());
        String request = "1successhuahua";
        boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
        System.out.println("登录校验：" + request + (success ? " 放行" : " 拦截"));
    }

}

总结
1：使用装饰器模式满足单一职责原则，你可以在自己的装饰类中完成功能逻辑的扩展，而不影响主类，同时可以按需在运行时添加和删除这部分逻辑。另外装饰器模式与继承父类重写方法，在某些时候需要按需选择，并不一定某一个就是最好。
2：装饰器实现的重点是对抽象类继承接口方式的使用，同时设定被继承的接口可以通过构造函数传递其实现类，由此增加扩展性并重写方法里可以实现此部分父类实现的功能。
就像夏天热你穿短裤，冬天冷你穿棉裤，雨天挨浇你穿雨衣一样，你的根本本身没有被改变，而你的3：需求却被不同的装饰而实现。生活中往往比比皆是设计，当你可以融合这部分活灵活现的例子到代码实现中，往往会创造出更加优雅的实现方式。

好了 至此 设计模式之装饰器模式(SSO单点登录功能扩展，增加拦截用户访问方法范围场景) 学习结束了 友友们 点点关注不迷路 老铁们！！！！！