多态通过面向接口编程和动态绑定实现解耦，要求使用接口类型声明变量、构造器注入依赖、DTO隔离业务语义、行为封装进领域对象。
多态本身不直接“降低耦合”，而是通过面向接口编程 + 运行时动态绑定，让调用方只依赖抽象契约，不依赖具体实现——这才是解耦的关键路径。
用接口引用代替实现类引用
调用方声明变量或参数时，类型必须是接口（如 PaymentService），而不是实现类（如 AlipayPaymentServiceImpl）。这样代码里就不会出现 new AlipayPaymentServiceImpl() 或 import xxx.impl 这类硬编码。
- Controller 层接收
PaymentService paymentService，而非某个具体支付实现 - 单元测试时可直接传入
new MockPaymentService()，无需 Spring 容器 - 切换微信支付时，只需替换构造参数或配置，不改 Controller 或 Service 逻辑
构造器注入保障依赖可见性
依赖必须显式传入，不能靠 ApplicationContext.getBean()、ServiceLoader.load() 或静态工具类查找。运行时对象创建要可控、可替换。
- 类内部禁止出现
new、单例静态工厂、全局查找逻辑 - 所有外部依赖都通过构造器参数或 setter 方法注入
- IDE 查看 “Find Usages” 时，能一眼看出该类依赖了哪些协作对象
DTO 隔离业务语义，避免三方模型污染
接口方法的参数和返回值必须是专为此业务场景设计的轻量 DTO（如 ChargeRequest、ChargeResult），不能是数据库实体、VO 或支付宝/微信的原始响应模型。
立即学习“Java免费学习笔记（深入）”；
-
ChargeRequest字段命名用业务语言（payeeAccount），不用技术字段（alipayUserId） - 异常统一为业务语义异常（
PaymentFailedException），不暴露底层 SDK 异常（AlipayApiException） - DTO 按业务变化原因聚合字段，不随第三方 API 或数据库结构频繁变动
行为封装进数据，减少工具类割裂
把校验、状态转换等逻辑放在领域对象内部，而不是抽成独立的 Helper 或 Utils 类。让数据和行为天然绑定，提升内聚，间接支撑低耦合。
-
order.transitionTo(PAID)封装在Order类中，而非散落在OrderService的 if-else 里 -
user.isValidEmail()是User自身的状态约束，比UserHelper.isValidEmail(user.getEmail())更内聚 - DTO 仅用于跨层传输（如 Controller → Service），不参与任何业务判断或格式化
