很多人写代码往往是没有编程感觉的，也就是除了可以把功能按照固定的流程编写出流水式的代码外，很难去思考整套功能服务的扩展性和可维护性。尤其是在一些较大型的功能搭建上，比较缺失一些驾驭能力，从而导致最终的代码相对来说不能做到尽善尽美。
江洋大盗与江洋大偷
两个本想描述一样的意思的词，只因一字之差就让人觉得一个是好牛，一个好搞笑。往往我们去开发编程写代码时也经常将一些不恰当的用法用于业务需求实现中，但却不能意识到。一方面是由于编码不多缺少较大型项目的实践，另一方面是不思进取的总在以完成需求为目标缺少精益求精的工匠精神。
书从来不是看的而是用的
在这个学习资料几乎爆炸的时代，甚至你可以轻易就获取几个T的视频，小手轻轻一点就收藏一堆文章，但却很少去看。学习的过程从不只是简单的看一遍就可以，对于一些实操性的技术书籍，如果真的希望学习到知识，那么一定是把这本书用起来而绝对不是看起来。
一、开发环境
-
二、装饰器模式介绍
初看上图感觉装饰器模式有点像俄罗斯套娃、某众汽车 ) ，而装饰器的核心就是再不改原有类的基础上给类新增功能。不改变原有类，可能有的小伙伴会想到继承、AOP切面，当然这些方式都可以实现，但是使用装饰器模式会是另外一种思路更为灵活，可以避免继承导致的子类过多，也可以避免AOP带来的复杂性。
你熟悉的场景很多用到装饰器模式
new BufferedReader(new FileReader(“”)); ，这段代码你是否熟悉，相信学习java开发到字节流、字符流、文件流的内容时都见到了这样的代码，一层嵌套一层，一层嵌套一层，字节流转字符流等等，而这样方式的使用就是装饰器模式的一种体现。三、案例场景模拟
在本案例中我们模拟一个单点登录功能扩充的场景
一般在业务开发的初期，往往内部的ERP使用只需要判断账户验证即可，验证通过后即可访问ERP的所有资源。但随着业务的不断发展，团队里开始出现专门的运营人员、营销人员、数据人员，每个人员对于ERP的使用需求不同，有些需要创建活动，有些只是查看数据。同时为了保证数据的安全性，不会让每个用户都有最高的权限。那么以往使用的 SSO 是一个组件化通用的服务，不能在里面添加需要的用户访问验证功能。这个时候我们就可以使用装饰器式，扩充原有的单点登录服务。但同时也保证原有功能不受破坏，可以继续使用。1. 场景模拟工程
这里模拟的是spring中的类： HandlerInterceptor ，实现接口功能 SsoInterceptor 模拟的单点登录拦截服务。
为了避免引入太多spring的内容影响对设计模式的阅读，这里使用了同名的类和方法，尽可能减少外部的依赖。2. 场景简述
2.1 模拟Spring的HandlerInterceptor
```java public interface HandlerInterceptor {
boolean preHandle(String request, String response, Object handler);
}
实际的单点登录开发会基于； org.springframework.web.servlet.HandlerInterceptor 实现。<a name="D6qqO"></a>### 2.2 模拟单点登录功能```javapublic class SsoInterceptor implements HandlerInterceptor{public boolean preHandle(String request, String response, Object handler) {// 模拟获取cookieString ticket = request.substring(1, 8);// 模拟校验return ticket.equals("success");}}
这里的模拟实现非常简单只是截取字符串，实际使用需要从 HttpServletRequest request 对象中获取 cookie 信息，解析 ticket 值做校验。
在返回的里面也非常简单，只要获取到了 success 就认为是允许登录。
四、用一坨坨代码实现
此场景大多数实现的方式都会采用继承类
继承类的实现方式也是一个比较通用的方式，通过继承后重写方法，并发将自己的逻辑覆盖进去。如果是一些简单的场景且不需要不断维护和扩展的，此类实现并不会有什么，也不会导致子类过多。
1. 工程结构
以上工程结构非常简单，只是通过 LoginSsoDecorator 继承 SsoInterceptor ，重写方法功能。
2. 代码实现
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");}@Overridepublic boolean preHandle(String request, String response, Object handler) {// 模拟获取cookieString 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);}}
以上这部分通过继承重写方法，将个人可访问哪些方法的功能添加到方法中。
以上看着代码还算比较清晰，但如果是比较复杂的业务流程代码，就会很混乱。
3. 测试验证
3.1 编写测试类
public class ApiTest {@Testpublic void test_LoginSsoDecorator() {LoginSsoDecorator ssoDecorator = new LoginSsoDecorator();String request = "1successhuahua";boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");System.out.println("登录校验：" + request + (success ? " 放行" : " 拦截"));}}
这里模拟的相当于登录过程中的校验操作，判断用户是否可登录以及是否可访问方法。
3.2 测试结果
从测试结果来看满足我们的预期，已经做了拦截。如果你在学习的过程中，可以尝试模拟单点登录并继承扩展功能。
五、装饰器模式重构代码
接下来使用装饰器模式来进行代码优化，也算是一次很小的重构。
装饰器主要解决的是直接继承下因功能的不断横向扩展导致子类膨胀的问题，而是用装饰器模式后就会比直接继承显得更加灵活同时这样也就不再需要考虑子类的维护。
在装饰器模式中有四个比较重要点抽象出来的点；
1. 抽象构件角色(Component) - 定义抽象接口
2. 具体构件角色(ConcreteComponent) - 实现抽象接口，可以是一组
3. 装饰角色(Decorator) - 定义抽象类并继承接口中的方法，保证一致性
4. 具体装饰角色(ConcreteDecorator) - 扩展装饰具体的实现逻辑
通过以上这四项来实现装饰器模式，主要核心内容会体现在抽象类的定义和实现上。
1. 工程结构
装饰器模式模型结构
以上是一个装饰器实现的类图结构，重点的类是 SsoDecorator ，这个类是一个抽象类主要完成了对接口 HandlerInterceptor 继承。
当装饰角色继承接口后会提供构造函数，入参就是继承的接口实现类即可，这样就可以很方便的扩展出不同功能组件。
2. 代码实现
2.1 抽象类装饰角色
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 。
以上三个点是装饰器模式的核心处理部分，这样可以踢掉对子类继承的方式实现逻辑功能扩展。
2.2 装饰角色逻辑实现
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);}@Overridepublic 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 的实现中可以看到，这里只关心扩展部分的功能，同时不会影响原有类的核心服务，也不会因为使用继承方式而导致的多余子类，增加了整体的灵活性。
3. 测试验证
3.1 编写测试类
public class ApiTest {@Testpublic void test_LoginSsoDecorator() {LoginSsoDecorator ssoDecorator = new LoginSsoDecorator(new SsoInterceptor());String request = "1successhuahua";boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");System.out.println("登录校验：" + request + (success ? " 放行" : " 拦截"));}}
这里测试了对装饰器模式的使用，通过透传原有单点登录类 new SsoInterceptor() ，传递给装饰器，让装饰器可以执行扩充的功能。
同时对于传递者和装饰器都可以是多组的，在一些实际的业务开发中，往也是由于太多类型的子类实现而导致不易于维护，从而使用装饰器模式替代。
3.2 测试结果
结果符合预期，扩展了对方法拦截的校验性。
如果你在学习的过程中有用到过单点登陆，那么可以适当在里面进行扩展装饰器模式进行学习使用。另外，还有一种场景也可以使用装饰器。例如；你之前使用某个实现某个接口接收单个消息，但由于外部的升级变为发送 list 集合消息，但你又不希望所有的代码类都去修改这部分逻辑。那么可以使用装饰器模式进行适配 list 集合，给使用者依然是 for 循环后的单个消息。
六、总结
使用装饰器模式满足单一职责原则，你可以在自己的装饰类中完成功能逻辑的扩展，而不影响主类，同时可以按需在运行时添加和删除这部分逻辑。另外装饰器模式与继承父类重写方法，在某些时候需要按需选择，并不一定某一个就是最好。装饰器实现的重点是对抽象类继承接口方式的使用，同时设定被继承的接口可以通过构造函数传递其实现类，由此增加扩展性并重写方法里可以实现此部分父类实现的功能。就像夏天热你穿短裤，冬天冷你穿棉裤，雨天挨你穿雨衣一样，你的根本身没有被改变，而你的需求却被不同的装饰而实现。生活中往往⽐比皆是设计，当你可以融合这部分活灵活现的例子到代码实现中，往往会创造出更加优雅的实现方式。
若有收获，就点个赞吧
0 人点赞
