面试官：我想问一个问题，项目中常见的问题面试官：我现在有一个系统，会根据请求的输入采取不同的动作。但是，这种不同的操作可能会改变需求。你会如何设计这个系统？面试官：实例：现在有多个第三方渠道，系统需要将订单归属于各个渠道。但是归因逻辑很可能会发生变化，不同渠道的归因逻辑也不同。这时候系统中的逻辑就比较复杂了。面试官：如果让你去优化，你会怎么设计？应聘者：我明白你的意思。考生：说到底还是处理逻辑比较复杂，ifelse判断太多了。考生：虽然有新的需求来了，但是可以加上ifelse来解决。应聘者：但是你想要的是一个更具扩展性和可维护性的系统应聘者：我想要一个我这边的解决方案来解决类似的问题应聘者：对吗？面试官：嗯……考生：这之前我一般都是在网上搜索ifelse怎么解决，大部分都说是策略模式考生：但是我举的例子并没有引起我的共鸣，而且很多次看完就通过了。考生：其实，在项目中，策略模式还是蛮多的，可能是无意中用到的（毕竟是面向接口编程）。项目中的做法是：ChainofResponsibilityModeCandidates：将每个流程单独抽取成一个Process（可以理解为一个模块或者节点），然后将请求塞入ContextCandidates：比如你有之前维护过一个项目，也类似于不同渠道使用不同的逻辑候选：我们这里的做法是将相关逻辑提取到Process中，给不同的渠道分配不同的责任链候选：比如A渠道的责任链是：WhiteListProcess->DataAssembleProcess->ChannelAProcess->SendProcessCandidate：而ChannelB的责任链为：WhiteListProcess->DataAssembleProcess->ChannelBProcess->SendProcessCandidate：在责任链的基础上，可以嵌入“脚本”候选代码作者：比如在SendProcess上，内置了发送消息的脚本（脚本可以选择不同的算子发送消息）。有了“脚本”，修改逻辑无需重启即可生效。考生：有人把这套东西叫做“规则引擎”。例如，规则引擎中著名的实现框架“Drools”就可以做类似的事情：将易于更改的逻辑写在“脚本”上（至少我们认为脚本和我们应用程序的真实逻辑是分开的）：（这里的脚本指的是规则集，可以是Droolsdsl、Groovy、aviator等）面试官：嗯……应聘者：在我之前的公司，用的是Groovy脚本。大致的实现逻辑是：有专门的后台管理脚本，然后将脚本写入“分布式配置中心”（实时刷新），客户端监控脚本是否存储在“分布式配置中心”有没有修改候选人：如果有变化，重新编译并通过Groovy类加载器加载脚本，最后放到Spring容器中供外部使用候选人：但是据我所知，我们的玩法业务在“责任链”是供程序员在“服务编排后台”配置信息（配置责任链的各个节点）。代码候选可以按照“服务编排”的流程执行：这样做的好处是业务链在后台配置，不需要在系统业务上维护链，灵活性更高（书面的责任链节点可以随意组合）面试官：那我明白了。欢迎关注我的微信公众号【Java3y】聊聊Java面试。在线面试官系列持续更新中！【在线面试官-手机版】系列，每周两篇，持续更新中！【在线面试官-电脑】系列每周两篇持续更新中！原创不易！！一连求三！！
