毕业设计中如何运用设计模式？

 大多数时候我都是写一些业务代码，可能一堆CRUD就能解决问题，但是这样的工作对技术人的提升并不多，如何让自己从业务中解脱出来找到写代码的乐趣呢，我做过一些尝试，使用设计模式改善自己的业务代码就是其中的一种。

设计模式实践

责任链设计模式

责任链设计模式定义

请求在一个链条上处理，链条上的受理者处理完毕之后决定是继续往后传递还是中断当前处理流程。

适用场景

适用于多节点的流程处理，每个节点完成各自负责的部分，节点之间不知道彼此的存在，比如OA的审批流，java web开发中的Filter机制。举一个生活中的例子，笔者之前租房的时候遇到了所谓的黑中介，租的时候感觉自己是上帝，但是坏了东西找他修的时候就像个孙子一样，中介让我找门店客服，门店客服又让我找房东，房东又让我找她家老公，最终好说歹说才把这事了了（租房一定要找正规中介）。

实践经验

笔者目前所做的业务是校园团餐的聚合支付，业务流程很简单，1.学生打开手机付款码支付，2.食堂大妈使用机具扫付款码收款。大学食堂有个背景是这样的，食堂有补贴，菜品比较便宜，所以学校是不愿意让社会人士去学校食堂消费的，鉴于此，我们在支付之前加了一套是否允许支付的检验逻辑，大体如下：

1.某档口只允许某类用户用户消费，比如教师档口只允许教师消费，学生档口不允许校外用户消费；

2.某个档口一天只允许某类用户消费几次，比如教师食堂一天只允许学生消费一次；

3.是否允许非清真学生消费，比如某些清真餐厅，是不允许非清真学生消费的；

针对这几类情况我建立了三类过滤器，分别是：

SpecificCardUserConsumeLimitFilter：按用户类型判断是否允许消费

DayConsumeTimesConsumeLimitFilter：按日消费次数判断是否允许消费

MuslimConsumeLimitFilter：非清真用户是否允许消费

判断逻辑是先通过SpecificCardUserConsumeLimitFilter判断当前用户是否可以在此档口消费，如果允许继续由DayConsumeTimesConsumeLimitFilter判断当天消费次数是否已用完，如果未用完继续由MuslimConsumeLimitFilter判断当前用户是否满足清真餐厅的就餐条件，前面三条判断，只要有一个不满足就提前返回。

总结

将每种限制条件的判断逻辑封装到了具体的Filter中，如果某种限制条件的逻辑有修改不会影响其他条件，如果需要新加限制条件只需要重新构造一个Filter织入到FilterChain上即可。

策略设计模式

策略设计模式定义

定义一系列的算法,把每一个算法封装起来, 并且使它们可相互替换

适用场景

主要是为了消除大量的if else代码，将每种判断背后的算法逻辑提取到具体的策略对象中，当算法逻辑修改时对使用者无感知，只需要修改策略对象内部逻辑即可。这类策略对象一般都实现了某个共同的接口，可以达到互换的目的。

实践经验

笔者之前有个需求是用户扫码支付以后向档口的收银设备推送一条支付消息，收银设备收到消息以后会进行语音播报，逻辑很简单，就是调用推送平台推送一条消息给设备即可，但是由于历史原因，某些设备对接的推送平台是不一样的，A类设备优先使用信鸽推送，如果失败了需要降级到长轮询机制，B类设备直接使用自研的推送平台即可，还有个现状是A类和B类的消息格式是不一样的（不同的团队开发，后期被整合到一起），鉴于此，我抽象出PushStrategy接口，其具体的实现有IotPushStrategy和XingePushStrategy，分别对应自研推送平台的推送策略和信鸽平台的推送策略，使用者时针对不同的设备类型使用不同的推送策略即可。

总结

将每种通道的推送逻辑封装到了具体的策略中，某种策略的变更不会影响其他策略，由于实现了共同接口，所以策略可以互相替换，对使用者友好，比如java ThreadPoolExecutor中的任务拒绝策略，当线程池已经饱和的时候会执行拒绝策略，具体的拒绝逻辑被封装到了RejectedExecutionHandler的rejectedExecution中。

模板设计模式

模板设计模式定义

模板的价值就在于骨架的定义，骨架内部将问题处理的流程已经定义好，通用的处理逻辑一般由父类实现，个性化的处理逻辑由子类实现。比如炒土豆丝和炒麻婆豆腐，大体逻辑都是1.切菜，2.放油，3.炒菜，4.出锅，1,2,4都差不多，但是第3步是不一样的，炒土豆丝得拿铲子翻炒，但是炒麻婆豆腐得拿勺子轻推，否则豆腐会烂（疫情宅在家，学了不少菜）。

使用场景

不同场景的处理流程，部分逻辑是通用的，可以放到父类中作为通用实现，部分逻辑是个性化的，需要子类去个性实现。

实践经验

还是接着之前语音播报的例子来说，后期我们新加了两个需求：1.消息推送需要增加trace

2.有些通道推送失败需要重试

所以现在的流程变成了这样：

1.trace开始

2.通道开始推送

3.是否允许重试，如果允许执行重试逻辑

4.trace结束