设计模式应用场景

 

设计模式在面试中被提到很多，程序员应该都知道常见的一些设计模式以及他的设计原理或多或少都了解。

书籍或者网上有许多介绍设计模式的文章，为了便于理解通常举例都是造车子造轮子这样偏离应用的例子。

 

作用

设计模式是一种思路，是一代又一代的程序员总结出来的经验

解耦，最大限度的实现代码的复用

便于维护，为了加强bug的可控性，出现问题能快速定位到bug

便于扩展，在后期加功能或者改功能的时候能以最小的改动达到最优的效果

例子

介绍几种我使用到的模式，然而每个人的业务场景都不一样，技术选型时要灵活运用。不积硅步无以至千里，技术永远都是只有在实践中运用理解才能提升。

支付模块(工厂模式)

应用场景：主要是支付的业务类型有多种，由类图中可以看到比如说商品的支付和活动的支付。而这两种业务的差别比较大，商品支付成功需要减去库存，通知卖家发货，活动支付成功需要发码，用户凭码入场。如果两个业务写在一起会导致代码可读性不好，后面维护的成本增加。

解决的问题：如图， 我们主要采用工厂模式。通过抽象出 IPayOrderServce,里面又个doPay()对外暴露。doPay()主要处理通用的业务，比如下单，不管是哪种支付业务都需要下单。还要调用抽象方法doMain(),各个业务继承接口实现doMain()处理自己特有的业务。PayOrderFactory()通过类型参数返回实现类，然后实现调用doPay()就能完成支付。

授权模块(模版模式)

 

应用场景：授权拦截有两种注解@Role和@Permission。两种业务需要处理和验证的逻辑也不尽相同，我们要实现的是自动检测和识别方法上的注解并完成权限验证。同样使用if else 也可以实现，但是为了代码优雅的表达出来可以用到设计模式。

解决问题：如图我们首先定义 AuthorizingAnnotationHandler，提供一个getAnnotationHandler()的方法。RoleAnnotationHandler和permissionAnnotationHandler继承抽象类定义需要验证的注解，实现抽象方法assertAuthorized()定义自己的验证逻辑。然后定义AuthorizingMethodInterceptor 暴露一个invoke()，invoke里面调用抽象方法assertAuthorized()。AuthorizingAnnotationMethodInterceptor继承 AuthorizingMethodInterceptor，构造方法初始化所有需要验证的实例。asserAuthorized()遍历所有实例，获取对应AuthorizingAnnotationHandler执行真正 asserAuthorized()验证逻辑。RoleAnnotationMethodInterceptor和PermissionAnnotationMethodIntercept 构造方法里面设置各自的AnnotationHandler。