策略模式的底层骨架是接口与多态：接口定义统一行为契约（如paymentstrategy），屏蔽算法细节；多态通过父类型引用指向子类对象，实现运行时动态绑定与策略替换。
接口与多态不是策略模式的“配套工具”，而是它的底层骨架。策略模式之所以能灵活切换算法、避免条件分支、符合开闭原则，根本原因就在于它天然依赖接口定义契约、靠多态实现运行时绑定。
接口定义统一行为契约
策略模式的第一步是声明一个抽象策略接口（如 PaymentStrategy 或 SortStrategy），里面只包含核心方法签名，不写实现。这个接口就是所有具体策略必须遵守的“协议”。
- 它屏蔽了算法细节，客户端只关心“能做什么”，不关心“怎么做”
- 新增策略时，只要实现该接口，系统其他部分完全不用改动
- 接口方法通常设计为无状态、可重入，便于在不同上下文中复用
多态支撑运行时策略替换
接口本身不能实例化，真正起作用的是多态——通过父类型引用指向子类对象，在调用时自动执行对应实现。
- 上下文类（Context）持有一个策略接口类型的字段，而非某个具体类
- 构造或设置策略时传入任意实现类（AlipayStrategy、WechatStrategy等），无需修改上下文逻辑
- 调用 pay() 或 sort() 时，JVM 根据实际对象类型动态绑定方法，这就是多态的本质
策略选择与注入更自然
有了接口和多态，策略的选用方式变得轻量且解耦：
- 可通过构造函数注入，适合策略相对固定
- 可用 setter 动态切换，适合运行时根据业务规则变更（如按金额阈值选支付方式）
- 结合 Spring 的 @Qualifier 或枚举驱动工厂，还能自动匹配策略，进一步隐藏选择逻辑
避免常见误用陷阱
接口+多态虽简洁，但容易忽略几个关键点：
- 策略类应尽量无状态；若需保存上下文数据，建议由上下文类传递，而非在策略内部维护
- 不要让策略之间产生强依赖或互相调用，否则破坏封装性
- 接口方法参数不宜过多，必要时可封装为参数对象，保持策略接口稳定
- 避免把策略当成万能工具类——它专注解决“同一件事的不同做法”，不是通用工具集合
