在Java开发中，一个比较流程的概念就是“设计模式”，特别是在一些基础框架中，更是充满了对各种设计模式的应用。
在应用软件开发行业从业了这么多年，也曾拜读过相关技术书籍，对于设计模式的名字也能娓娓道来，但是对于设计模式的理解，似乎一直以来都不深刻，换言之：只学到了设计模式的概念，并没有真正吃透设计模式存在的意义以及如何在项目中灵活运用。在过往的软件开发项目中，也层主动或被动地使用过一些常用的设计模式，但是并没有真正领悟到设计模式的所带来的好处，似乎是一种顺其自然的使用。
直到今天再次应用“责任链模式”解决支付网关的切换问题时，才从心底感受到设计模式所带来的益处。
结合这么多年的开发实践，说说我对设计模式的理解：简化代码结构，便于理解，维护和迭代，这是最直接的收益。
反之，如果不应用设计模式，那么编写出来的代码可能充斥着大量的if...else...结构，不利用项目演进过程中的迭代和扩展。
业务场景举例：
支付中心同时对接了原生支付宝支付和微信支付，还需要接入付呗支付（注：付呗支付本质上对接的也是支付宝和微信支付）。产品设计如下规则：原生支付宝存在收款限额，当超过设定的指定限额时直接切换使用付呗支付宝支付；另外，设定支付比例，比如：20%的请求使用原生支付宝和原生微信支付，80%的请求使用付呗支付宝和付呗微信支付；统计失败率，当原生支付宝/微信 或 付呗支付宝/微信的失败率超过某个阈值后自动切换成另一种支付渠道。
针对上述业务场景，如果不使用任何设计模式，编写出的代码结果可能是如下情况：
# 伪代码：硬编码的弊端
def pay(amount, pay_type):
if pay_type == "alipay":
# 先判断比例
if random.random() < 0.2:
# 再判断原生支付宝是否可用+是否超限额
if 原生支付宝可用 and amount <= 限额:
return 原生支付宝支付()
else:
# 切付呗支付宝
if 付呗支付宝可用:
return 付呗支付宝支付()
else:
return 支付失败
else:
# 80%走付呗
if 付呗支付宝可用:
return 付呗支付宝支付()
else:
# 降级到原生
if 原生支付宝可用 and amount <= 限额:
return 原生支付宝支付()
else:
return 支付失败
# 微信同理，重复大量代码这种实现的问题：耦合严重（改比例要动所有 if）、扩展性差（新增渠道要加大量 if）、维护难（规则嵌套层级深，定位问题繁琐）、无法动态熔断（失败率判断要嵌入每个分支）。
如果使用责任链模式能将这些判断逻辑完全拆分，让每个节点只做一件事，完美规避以上问题，这就是设计模式的价值所在。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达，在下面评论区告诉我^_^^_^
