面试官：我想问个问题哈，我的项目里比拟常见的问题
面试官 ： 我当初有个零碎会依据申请的入参，做出不同动作。然而，这块不同的动作很有可能是会产生需要变动的，这块零碎你会怎么样设计？
面试官 ： 理论的例子：当初有多个第三方渠道，零碎须要对各种渠道进行订单归因。然而归因的逻辑很有可能会发生变化，不同的渠道归因的逻辑也不太一样，此时零碎里的逻辑绝对比较复杂。
面试官 ： 如果让你优化，你会怎么设计？
候选者：我了解你的意思了
候选者：归根到底，就是解决的逻辑绝对简单，if else 的判断太多了
候选者：尽管新的需要来了，都能够增加 if else 进行解决
候选者：但你想要的就是，零碎的可扩展性和可维护性更强
候选者：想要我这边出一个计划，来解决相似的问题
候选者：对吧？
面试官：嗯…
候选者：在这之前，个别上网搜如何解决 if else，大多数都说是 策略模式
候选者：然而举的例子又没感同身受，很多时候看完就过来了
候选者：实际上，在我的项目里边，用策略模式还是蛮多的，可能无意间就曾经用上了（毕竟面向接口编程嘛）
候选者：而我认为，策略模式不是解决 if else 的要害
候选者：这个问题，我的我的项目里的做法是：责任链模式
候选者：把每个流程独自抽取成一个 Process(能够了解为一个模块或节点)，而后申请都会塞进 Context 中
候选者：比方，之前保护过一个我的项目，也是相似于不同的渠道走不同的逻辑
候选者：咱们这边的做法是：抽取相干的逻辑到 Process 中，为不同的渠道调配不同的责任链
候选者：比方渠道 A 的责任链是：WhiteListProcess->DataAssembleProcess->ChannelAProcess->SendProcess
候选者：而渠道 B 的责任链是：WhiteListProcess->DataAssembleProcess->ChannelBProcess->SendProcess
候选者：在责任链根底之上，又能够在代码里内嵌「脚本」
候选者：比方在 SendProcess 上，内置发送音讯的脚本（脚本能够抉择不同的运营商进行发送音讯）。有了「脚本」当前，那就能够做到对逻辑的改变不须要重启就能够失效。
候选者：有人把这一套货色叫做「规定引擎」。比方，规定引擎中比拟闻名的实现框架「Drools」就能够做到相似的事
候选者：把易改变的逻辑写在「脚本」上（至多咱们认为，脚本和咱们的利用实在逻辑是拆散）
候选者：（脚本我这里指的是规定集，它能够是 Drools 的 dsl，也能够是 Groovy，也能够是 aviator 等等）
面试官：嗯…
候选者：在我之前的公司，应用的是 Groovy 脚本。大抵的实现逻辑就是：有专门后盾对脚本进行治理，而后会把脚本写到「分布式配置核心」（实时刷新），客户端监听「分布式配置核心」所存储的脚本是否有改变
候选者：如果存在改变，则通过 Groovy 类加载器从新编译并加载脚本，最初放到 Spring 容器对外应用
候选者：我目前所负责的零碎就是这样解决 多变 以及需要变更频繁的业务（责任链 + 规定引擎）
候选者：不过据我理解，咱们的玩法业务又在「责任链」多做了些事件
候选者：「责任链」不再从代码里编写，而是下沉到平台去做「服务编排」，就是由程序员去「服务编排后盾」上配置信息（配置责任链的每一个节点）
候选者：在业务零碎里应用「服务编排」的客户端，申请时只有传入「服务编排」的 ID，就能够按「服务编排」的流程执行代码
候选者：这样做的益处就是：业务链是在后盾配置的，不必在零碎业务上保护链，灵活性更高（写好的责任链节点能够随便组合）
面试官：那我懂了
欢送关注我的微信公众号【Java3y】来聊聊 Java 面试，对线面试官系列继续更新中！
【对线面试官 - 挪动端】系列 一周两篇继续更新中！
【对线面试官 - 电脑端】系列 一周两篇继续更新中！
原创不易！！求三连！！