策略模式的底层骨架是接口与多态：接口定义统一行为契约（如PaymentStrategy），屏蔽算法细节；多态通过父类型引用指向子类对象，实现运行时动态绑定与策略替换。

接口与多态不是策略模式的“配套工具”，而是它的底层骨架。策略模式之所以能灵活切换算法、避免条件分支、符合开闭原则，根本原因就在于它天然依赖接口定义契约、靠多态实现运行时绑定。

接口定义统一行为契约

策略模式的第一步是声明一个抽象策略接口（如 PaymentStrategy 或 SortStrategy），里面只包含核心方法签名，不写实现。这个接口就是所有具体策略必须遵守的“协议”。

• 它屏蔽了算法细节，客户端只关心“能做什么”，不关心“怎么做”
• 新增策略时，只要实现该接口，系统其他部分完全不用改动
• 接口方法通常设计为无状态、可重入，便于在不同上下文中复用

多态支撑运行时策略替换

接口本身不能实例化，真正起作用的是多态——通过父类型引用指向子类对象，在调用时自动执行对应实现。

• 上下文类（Context）持有一个策略接口类型的字段，而非某个具体类
• 构造或设置策略时传入任意实现类（AlipayStrategy、WechatStrategy等），无需修改上下文逻辑
• 调用 pay() 或 sort() 时，JVM 根据实际对象类型动态绑定方法，这就是多态的本质

策略选择与注入更自然

有了接口和多态，策略的选用方式变得轻量且解耦：

• 可通过构造函数注入，适合策略相对固定
• 可用 setter 动态切换，适合运行时根据业务规则变更（如按金额阈值选支付方式）
• 结合 Spring 的 @Qualifier 或枚举驱动工厂，还能自动匹配策略，进一步隐藏选择逻辑

避免常见误用陷阱

接口+多态虽简洁，但容易忽略几个关键点：

• 策略类应尽量无状态；若需保存上下文数据，建议由上下文类传递，而非在策略内部维护
• 不要让策略之间产生强依赖或互相调用，否则破坏封装性
• 接口方法参数不宜过多，必要时可封装为参数对象，保持策略接口稳定
• 避免把策略当成万能工具类——它专注解决“同一件事的不同做法”，不是通用工具集合