设计模式 - 结构型模式_外观模式
文章目录
结构型模式
结构型模式主要是解决如何将对象和类组装成较大的结构， 并同时保持结构的灵活和⾼效。
结构型模式包括：适配器、桥接、组合、装饰器、外观、享元、代理，这7类
概述
设计模式是解决程序中不合理、不易于扩展、不易于维护的问题，也是⼲掉⼤部分 ifelse 的利器，在我们常⽤的框架中基本都会⽤到⼤量的设计模式来构建组件，这样也能⽅便框架的升级和功能的扩展。
但如果不能合理的设计以及乱⽤设计模式，会导致整个编程变得更加复杂难维护，也就是我们常说的: 反设计 、 过渡设计 。⽽这部分设计能⼒也是从实践的项⽬中获取的经验，不断的改造优化摸索出的最合理的⽅式，应对当前的服务体量。
外观模式也叫⻔⾯模式，主要解决的是降低调⽤⽅的使⽤接⼝的复杂逻辑组合。这样调⽤⽅与实际的接⼝提供⽅提供⽅提供了⼀个中间层，⽤于包装逻辑提供API接⼝。
有些时候外观模式也被⽤在中间件层，对服务中的通⽤性复杂逻辑进⾏中间件层包装，让使⽤⽅可以只关⼼业务开发。
那么这样的模式在我们的所⻅产品功能中也经常遇到，就像⼏年前注册⼀个⽹站时候往往要添加很多信息，包括: 姓名、昵称、⼿机号、QQ、邮箱、住址、单身等等，但现在注册成为⼀个⽹站的⽤户只需要⼀步即可，⽆论是⼿机号还是微信也都提供了这样的登录服务。⽽对于服务端应⽤开发来说以前是提供了⼀个整套的接⼝，现在注册的时候并没有这些信息，那么服务端就需要进⾏接⼝包装，在前端调⽤注册的时候服务端获取相应的⽤户信息(从各个渠道)，如果获取不到会让⽤户后续进⾏补全(营销补全信息给奖励)，以此来拉动⽤户的注册量和活跃度。
Case
模拟⼀个将所有服务接⼝添加⽩名单的场景。
我们知道，每⼀次发版上线都需要进⾏测试，⽽这部分测试验证⼀般会进⾏⽩名单开量或者切量的⽅式进⾏验证。那么如果在每⼀个接⼝中都添加这样的逻辑，就会⾮常麻烦且不易维护。另外这是⼀类具备通⽤逻辑的共性需求，⾮常适合开发成组件，以此来治理服务，让研发⼈员更多的关⼼业务功能开发。
⼀般情况下对于外观模式的使⽤通常是⽤在复杂或多个接⼝进⾏包装统⼀对外提供服务上，此种使⽤⽅式也相对简单在我们平常的业务开发中也是最常⽤的。我们可能经常听到把这两个接⼝包装⼀下，但在本例⼦中我们把这种设计思路放到中间件层，让服务变得可以统⼀控制。
【场景模拟⼯程】
SpringBoot 的 HelloWorld ⼯程，在⼯程中提供了查询⽤户信息的接⼝HelloWorldController.queryUserInfo ，为后续扩展此接⼝的⽩名单过滤做准备。
【定义基础查询接⼝】
@RestController
public class HelloWorldController {
@Value("${server.port}")
private int port;
/**
* key：需要从入参取值的属性字段，如果是对象则从对象中取值，如果是单个值则直接使用
* returnJson：预设拦截时返回值，是返回对象的Json
*
* http://localhost:8080/api/queryUserInfo?userId=1001
* http://localhost:8080/api/queryUserInfo?userId=小团团
*/
@RequestMapping(path = "/api/queryUserInfo", method = RequestMethod.GET)
public UserInfo queryUserInfo(@RequestParam String userId) {
return new UserInfo("虫虫:" + userId, 19, "天津市南开区旮旯胡同100号");
}
}这⾥提供了⼀个基本的查询服务，通过⼊参 userId ，查询⽤户信息。后续就需要在这⾥扩展⽩名单，只有指定⽤户才可以查询，其他⽤户不能查询。
【Application启动类】
@SpringBootApplication
@Configuration
public class HelloWorldApplication {
public static void main(String[] args) {
SpringApplication.run(HelloWorldApplication.class, args);
}
}通⽤的 SpringBoot 启动类。需要添加的是⼀个配置注解 @Configuration ，为了后续可以读取⽩名单配置。
Bad Impl
⼀般对于此种场景最简单的做法就是直接修改代码 . 累加 if 块⼏乎是实现需求最快也是最慢的⽅式，快是修改当前内容很快，慢是如果同类的内容⼏百个也都需要如此修改扩展和维护会越来越慢。
public class HelloWorldController {
public UserInfo queryUserInfo(@RequestParam String userId) {
// 做白名单拦截
List<String> userList = new ArrayList<String>();
userList.add("1001");
userList.add("aaaa");
userList.add("ccc");
if (!userList.contains(userId)) {
return new UserInfo("1111", "非白名单可访问用户拦截！");
}
return new UserInfo("虫虫:" + userId, 19, "天津市南开区旮旯胡同100号");
}
}以上的实现是模拟⼀个Api接⼝类，在⾥⾯添加⽩名单功能，但类似此类的接⼝会有很多都需要修改，所以这也是不推荐使⽤此种⽅式的重要原因.
- 在这⾥⽩名单的代码占据了⼀⼤块，但它⼜不是业务中的逻辑，⽽是因为我们上线过程中需要做的开量前测试验证。
- 如果⽇常对待此类需求经常是这样开发，那么可以按照此设计模式进⾏优化，让后续的扩展和摘除更加容易
Better Impl
接下来使⽤外观器模式来进⾏代码优化，也算是⼀次很⼩的重构
这次重构的核⼼是使⽤外观模式也可以说⻔⾯模式，结合 SpringBoot 中的⾃定义 starter 中间件开发的⽅式，统⼀处理所有需要⽩名单的地⽅。
- SpringBoot的starter中间件开发⽅式。
- ⾯向切⾯编程和⾃定义注解的使⽤。
- 外部⾃定义配置信息的透传，SpringBoot与Spring不同，对于此类⽅式获取⽩名单配置存在差异。
【⼯程结构】
【⻔⾯模式模型结构】
- 以上是外观模式的中间件实现思路，右侧是为了获取配置⽂件，左侧是对于切⾯的处理。
- ⻔⾯模式可以是对接⼝的包装提供出接⼝服务，也可以是对逻辑的包装通过⾃定义注解对接⼝提供服务能⼒。
【配置服务类】
public class StarterService {
private String userStr;
public StarterService(String userStr) {
this.userStr = userStr;
}
public String[] split(String separatorChar) {
return StringUtils.split(this.userStr, separatorChar);
}
}以上类的内容较简单只是为了获取配置信息。
【配置类注解定义】
@ConfigurationProperties("artisan.door")
public class StarterServiceProperties {
private String userStr;
public String getUserStr() {
return userStr;
}
public void setUserStr(String userStr) {
this.userStr = userStr;
}
}⽤于定义好后续在 application.yml 中添加 artisan.door 的配置信息。
【⾃定义配置类信息获取】
@Configuration
@ConditionalOnClass(StarterService.class)
@EnableConfigurationProperties(StarterServiceProperties.class)
public class StarterAutoConfigure {
@Autowired
private StarterServiceProperties properties;
@Bean
@ConditionalOnMissingBean
@ConditionalOnProperty(prefix = "artisan.door", value = "enabled", havingValue = "true")
StarterService starterService() {
return new StarterService(properties.getUserStr());
}
}以上代码是对配置的获取操作，主要是对注解的定义: @Configuration 、 @ConditionalOnClass 、 @EnableConfigurationProperties ，这
⼀部分主要是与SpringBoot的结合使⽤.
【切⾯注解定义】
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface DoDoor {
String key() default "";
String returnJson() default "";
}定义了外观模式⻔⾯注解，后续就是此注解添加到需要扩展⽩名单的⽅法上
这⾥提供了两个⼊参
- key：获取某个字段例如⽤户ID
- returnJson：确定⽩名单拦截后返回的具体内容
【⽩名单切⾯逻辑】
@Aspect
@Component
public class DoJoinPoint {
private Logger logger = LoggerFactory.getLogger(DoJoinPoint.class);
@Autowired
private StarterService starterService;
@Pointcut("@annotation(com.artisan.design.door.annotation.DoDoor)")
public void aopPoint() {
}
@Around("aopPoint()")
public Object doRouter(ProceedingJoinPoint jp) throws Throwable {
//获取内容
Method method = getMethod(jp);
DoDoor door = method.getAnnotation(DoDoor.class);
//获取字段值
String keyValue = getFiledValue(door.key(), jp.getArgs());
logger.info("artisan door handler method：{} value：{}", method.getName(), keyValue);
if (null == keyValue || "".equals(keyValue)) return jp.proceed();
//配置内容
String[] split = starterService.split(",");
//白名单过滤
for (String str : split) {
if (keyValue.equals(str)) {
return jp.proceed();
}
}
//拦截
return returnObject(door, method);
}
private Method getMethod(JoinPoint jp) throws NoSuchMethodException {
Signature sig = jp.getSignature();
MethodSignature methodSignature = (MethodSignature) sig;
return getClass(jp).getMethod(methodSignature.getName(), methodSignature.getParameterTypes());
}
private Class<? extends Object> getClass(JoinPoint jp) throws NoSuchMethodException {
return jp.getTarget().getClass();
}
//返回对象
private Object returnObject(DoDoor doGate, Method method) throws IllegalAccessException, InstantiationException {
Class<?> returnType = method.getReturnType();
String returnJson = doGate.returnJson();
if ("".equals(returnJson)) {
return returnType.newInstance();
}
return JSON.parseObject(returnJson, returnType);
}
//获取属性值
private String getFiledValue(String filed, Object[] args) {
String filedValue = null;
for (Object arg : args) {
try {
if (null == filedValue || "".equals(filedValue)) {
filedValue = BeanUtils.getProperty(arg, filed);
} else {
break;
}
} catch (Exception e) {
if (args.length == 1) {
return args[0].toString();
}
}
}
return filedValue;
}
}这⾥包括的内容较多，核⼼逻辑主要是 Object doRouter(ProceedingJoinPoint jp) ，接下来我们分别介绍。
@Pointcut("@annotation(org.itstack.demo.design.door.annotation.DoDoor)")定义切⾯，这⾥采⽤的是注解路径，也就是所有的加⼊这个注解的⽅法都会被切⾯进⾏管理。
getFiledValue获取指定key也就是获取⼊参中的某个属性，这⾥主要是获取⽤户ID，通过ID进⾏拦截校验。
returnObject返回拦截后的转换对象，也就是说当⾮⽩名单⽤户访问时则返回⼀些提示信息
doRouter切⾯核⼼逻辑，这⼀部分主要是判断当前访问的⽤户ID是否⽩名单⽤户，如果是则放⾏ jp.proceed(); ，否则返回⾃定义的拦截提示信息。
【配置文件】
server:
port: 8080
spring:
application:
name: helloworld-door
# 自定义中间件配置
artisan:
door:
enabled: true
userStr: 1001,aaaa,ccc #白名单用户ID，多个逗号隔开这⾥主要是加⼊了⽩名单的开关和⽩名单的⽤户ID，逗号隔开。
【在Controller中添加⾃定义注解】
/**
* @DoDoor 自定义注解
* key：需要从入参取值的属性字段，如果是对象则从对象中取值，如果是单个值则直接使用
* returnJson：预设拦截时返回值，是返回对象的Json
*
* http://localhost:8080/api/queryUserInfo?userId=1001
* http://localhost:8080/api/queryUserInfo?userId=小团团
*/
@DoDoor(key = "userId", returnJson = "{\"code\":\"1111\",\"info\":\"非白名单可访问用户拦截！\"}")
@RequestMapping(path = "/api/queryUserInfo", method = RequestMethod.GET)
public UserInfo queryUserInfo(@RequestParam String userId) {
return new UserInfo("虫虫:" + userId, 19, "天津市南开区旮旯胡同100号");
}- 这⾥核⼼的内容主要是⾃定义的注解的添加 @DoDoor ，也就是我们的外观模式中间件化实现。
- key：需要从⼊参取值的属性字段，如果是对象则从对象中取值，如果是单个值则直接使⽤。
- returnJson：预设拦截时返回值，是返回对象的Json。
【启动SpringBoot】
⽩名单⽤户访问
http://localhost:8080/api/queryUserInfo?userId=1001返回
{"code":"0000","info":"success","name":"⾍⾍:1001","age":19,"address":"天津市
南开区旮旯胡同100号"}此时的测试结果正常，可以拿到接⼝数据
⾮⽩名单⽤户访问
http://localhost:8080/api/queryUserInfo?userId=⼩团团{"code":"1111","info":"⾮⽩名单可访问⽤户拦
截！","name":null,"age":null,"address":null}把 userId 换成 ⼩团团 ，此时返回的信息已经是被拦截的信息。⽽这个拦截信息正式我们⾃定义注解中的信息：
@DoDoor(key = "userId", returnJson = "
{\"code\":\"1111\",\"info\":\"⾮⽩名单可访问⽤户拦截！\"}")小结
通过中间件的⽅式实现外观模式，这样的设计可以很好的增强代码的隔离性，以及复⽤性，不仅使⽤上⾮常灵活也降低了每⼀个系统都开发这样的服务带来的⻛险。
只是⾮常简单的⽩名单控制，是否需要这样的处理。但往往⼀个⼩⼩的开始会影响着后续⽆限的扩展，实际的业务开发往往也要复杂的很多，不可能如此简单。因⽽使⽤设计模式来让代码结构更加⼲净整洁。
腾讯云开发者
