在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）、维护难（规则嵌套层级深，定位问题繁琐）、无法动态熔断（失败率判断要嵌入每个分支）。

如果使用责任链模式能将这些判断逻辑完全拆分，让每个节点只做一件事，完美规避以上问题，这就是设计模式的价值所在。