旁边工位的同事，不知姓谁名谁，甚至想不起什么时候调到这个组的。
在脑海中搜寻了许久，才些些想起一点关于他的初印象。大学毕业没几年，穿着简单干净，工作一丝不苟，从不迟到早退。总之，是个规规矩矩的人。但他有一个特别不好的习惯，就是整天琢磨设计模式、DDD之类虚无缥缈的玩意。有一次午休，我起身去倒水，看到他正在看《设计模式那些事儿》，还对照着作者在gitee的开源代码在练习，看样子似乎是想应用到项目中。
作为组里的老人，以及编程路上的过来人，我不由得想要跟他分享一些经验。我说，这些设计模式用处不大，程序就是数据结构+算法，if else能解决的事情，搞这么复杂干嘛。你看我们现在交易链路这么复杂，不照样能跑么。
他听罢连连称是：黄哥你说得对，我还要跟你多学习。
有一天，我与隔壁业务组对接一个需求。对方告诉我，你旁边工位的同事之前写过第一版，所以这次不需要重新写，在上面迭代就行了。我回到工位搜索类名，发现确实有一个Rpc接口：PromotionRightsSendRpc。
这个接口有一个batchSend方法，支持对用户批量发放权益，比如优惠券、返现卡等，而我这次要做的就是把前阵子刚实现的赠品卡接进去。
正当我准备写if逻辑时，我发现之前的代码竟然没有一个if else。
我心里一惊，这是什么写法？优惠券的实现在哪？经过一开始的错愕，终于让我找到了门路。这里存在一个继承体系：
好在我十几年前刚入行时学过一点面向对象，这里利用多态，最终由子类实现batchSend。诶？等等，好像不对。子类怎么只有send方法，没有batchSend。
我进入到Abstract类，才明白其中门道。
原来这小子把通用的record、recordDetail的记录操作给抽取到Abstract类了，这两张表在部分失败、以及后续重试时很有用。
看到这里，我大致了解小伙子的设计思路了，还算不错，我扩展起来也很方便。但是，这个BatchResult怎么这么复杂？
仔细观察后，我发现小伙子把它下沉到common包了，说明他认为这个类具备通用性。这不禁让我来了兴趣，当即在类的空白处试着使用BatchResult：
我再次惊讶于，这个类使用了和MyBatis-Plus类似的写法，虽然不知道这是什么设计，但蛮好用的。更让人震惊的是，分别调用finished()和interrupted()得到的后续操作并不相同。
比如调用interrupted()后，可以追加失败原因：
再调用result设置结果：
这...是我旁边的小伙子写的吗？
「いつの間にかこんなに成長したの？！」
我转过头问小伙子，他摸摸后脑勺笑着回答道，我瞎写的，就是想帮大家省点时间，把API设计得用起来舒服些。
那一刻我才发现，原来设计模式并非一无是处，原来爱用设计模式的也未必是“手里拿着锤子，看什么都是钉子”的人，也可能是组里那个默不作声却异常温柔的人。
gitee开源：设计模式那些事儿
