@[toc]
结构型模式
结构型模式主要是解决如何将对象和类组装成较大的结构， 并同时保持结构的灵活和⾼效。
结构型模式包括：适配器、桥接、组合、装饰器、外观、享元、代理，这7类
概述
装饰器的核⼼就是再不改原有类的基础上给类新增功能。
不改变原有类，大家会想到继承、AOP切⾯，当然这些⽅式都可以实现，但是使⽤装饰器模式会是另外⼀种思路更为灵活，可以避免继承导致的⼦类过多，也可以避免AOP带来的复杂性。
很多场景⽤到装饰器模式 new BufferedReader(new FileReader("")); 字节流、字符流、⽂件流的内容时都⻅到了这样的代码，⼀层嵌套⼀层，⼀层嵌套⼀层，字节流转字符流等等，⽽这样⽅式的使⽤就是装饰器模式的⼀种体现。
Case
模拟⼀个单点登录功能扩充的场景
以往使⽤的 SSO 是⼀个组件化通⽤的服务，不能在⾥⾯添加需要的⽤户访问验证功能。这个时候我们可以使⽤装饰器模式，扩充原有的单点登录服务。但同时也保证原有功能不受破坏，可以继续使⽤。
【工程结构】
- 模拟spring中的类：
HandlerInterceptor，实现接⼝功能SsoInterceptor模拟的单点登录拦截服务。
【模拟Spring的HandlerInterceptor】
public interface HandlerInterceptor {
boolean preHandle(String request, String response, Object handler);
}
实际的单点登录开发会基于 org.springframework.web.servlet.HandlerInterceptor 实现。
【模拟单点登录功能】
public class SsoInterceptor implements HandlerInterceptor{
public boolean preHandle(String request, String response, Object handler) {
// 模拟获取cookie
String ticket = request.substring(1, 8);
// 模拟校验
return ticket.equals("success");
}
}
- 模拟实现⾮常简单只是截取字符串，实际使⽤需要从
HttpServletRequest request对象中获取cookie信息，解析ticket值做校验。 - 在返回的⾥⾯也⾮常简单，只要获取到了
success就认为是允许登录。
Bad Impl
此场景⼤多数实现的⽅式都会采⽤继承类
继承类的实现⽅式也是⼀个⽐较通⽤的⽅式，通过继承后重写⽅法，并发将⾃⼰的逻辑覆盖进去。如果是⼀些简单的场景且不需要不断维护和扩展的，此类实现并不会有什么，也不会导致⼦类过多。
⼯程结构⾮常简单，只是通过 LoginSsoDecorator 继承 SsoInterceptor ，重写⽅法功能。
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(8);
String method = authMap.get(userId);
// 模拟方法校验
return "queryUserInfo".equals(method);
}
}
- 以上这部分通过继承重写⽅法，将个⼈可访问哪些⽅法的功能添加到⽅法中。
- 以上看着代码还算⽐较清晰，但如果是⽐较复杂的业务流程代码，就会很混乱。
【单元测试】
@Test
public void test_LoginSsoDecorator() {
LoginSsoDecorator ssoDecorator = new LoginSsoDecorator();
String request = "1successhuahua";
boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
System.out.println("登录校验：" + request + (success ? " 放行" : " 拦截"));
}模拟的相当于登录过程中的校验操作，判断⽤户是否可登录以及是否可访问⽅法。
Better Impl
接下来使⽤装饰器模式来进⾏代码优化，也算是⼀次很⼩的重构
装饰器主要解决的是直接继承下因功能的不断横向扩展导致⼦类膨胀的问题，⽽是⽤装饰器模式后就会⽐直接继承显得更加灵活同时这样也就不再需要考虑⼦类的维护。
在装饰器模式中有四个⽐较重要点抽象出来的点；
- 抽象构件⻆⾊(Component) - 定义抽象接⼝
- 具体构件⻆⾊(ConcreteComponent) - 实现抽象接⼝，可以是⼀组
- 装饰⻆⾊(Decorator) - 定义抽象类并继承接⼝中的⽅法，保证⼀致性
- 具体装饰⻆⾊(ConcreteDecorator) - 扩展装饰具体的实现逻辑
通过以上这四项来实现装饰器模式，主要核⼼内容会体现在抽象类的定义和实现上
【工程结构】
【装饰器模式模型结构】
- 以上是⼀个装饰器实现的类图结构，重点的类是
SsoDecorator，这个类是⼀个抽象类主要完成了对接⼝HandlerInterceptor继承 - 当装饰⻆⾊继承接⼝后会提供构造函数，⼊参就是继承的接⼝实现类即可，这样就可以很⽅便的扩展出不同功能组件
【抽象类装饰⻆⾊】
public abstract class SsoDecorator implements HandlerInterceptor {
private HandlerInterceptor handlerInterceptor;
private SsoDecorator(){}
public SsoDecorator(HandlerInterceptor handlerInterceptor) {
this.handlerInterceptor = handlerInterceptor;
}
public boolean preHandle(String request, String response, Object handler) {
return handlerInterceptor.preHandle(request, response, handler);
}
}
- 在装饰类中有两个重点的地⽅是；1)实现了处理接⼝、2)提供了构造函数、3)覆盖了⽅法
preHandle。 - 以上三个点是装饰器模式的核⼼处理部分，这样可以踢掉对⼦类继承的⽅式实现逻辑功能扩展
【装饰⻆⾊逻辑实现】
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 - 在
preHandle的实现中可以看到，这⾥只关⼼扩展部分的功能，同时不会影响原有类的核⼼服务，也不会因为使⽤继承⽅式⽽导致的多余⼦类，增加了整体的灵活性、
【单元测试】
@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 ? " 放行" : " 拦截"));
}- 结果符合预期，扩展了对⽅法拦截的校验性
还有⼀种场景也可以使⽤装饰器。例如：之前使⽤某个实现某个接⼝接收单个消息，但由于外部的升级变为发送 list 集合消息，但你⼜不希望所有的代码类都去修改这部分逻辑。那么可以使⽤装饰器模式进⾏适配 list 集合，给使⽤者依然是 for 循环后的单个消息。
小结
使⽤装饰器模式满⾜单⼀职责原则，你可以在⾃⼰的装饰类中完成功能逻辑的扩展，⽽不影响主类，同时可以按需在运⾏时添加和删除这部分逻辑。
另外装饰器模式与继承⽗类重写⽅法，在某些时候需要按需选择，并不⼀定某⼀个就是最好。
装饰器实现的重点是对抽象类继承接⼝⽅式的使⽤，同时设定被继承的接⼝可以通过构造函数传递其实现类，由此增加扩展性并重写⽅法⾥可以实现此部分⽗类实现的功能。
就像夏天穿短裤，冬天穿棉裤，⾬天穿⾬⾐⼀样，人本身没有被改变，⽽需求却被不同的装饰⽽实现。⽣活中往往⽐⽐皆是设计，当你可以融合这部分活灵活现的例⼦到代码实现中，往往会创造出更加优雅的实现⽅式。
