java多态配合接口实现松耦合架构，核心是用接口定义行为契约、多态实现运行时动态绑定，调用方仅依赖接口而不感知具体实现类，从而解耦模块；通过spring依赖注入、工厂或策略模式进一步外移对象创建逻辑，并需遵守禁止instanceof判断、接口命名体现业务意图等设计习惯。
Java 多态配合接口实现松耦合架构，核心在于用接口定义行为契约，用多态实现运行时动态绑定——调用方只依赖接口，不感知具体实现类，从而把模块之间的强依赖关系打破。
接口作为统一契约，隔离变化
接口不包含实现细节，只声明方法签名和业务语义。比如定义一个 NotificationService 接口：
- 所有通知方式（短信、邮件、站内信）都实现它
- 业务代码中只声明
NotificationService notifier，不写new SmsNotifier() - 当新增钉钉通知时，只需新增一个实现类，完全不用修改发通知的业务逻辑
多态让调用方“看不见”实现类
通过接口类型引用子类对象，JVM 在运行时自动分派到真实实现：
NotificationService service = new EmailNotifier();-
service.send("订单已支付");—— 编译期只检查接口方法是否存在，运行期才决定执行哪个 send 方法 - 配合 Spring 的依赖注入，甚至可以配置化切换实现：
@Qualifier("wechat") NotificationService
结合工厂或策略模式进一步解耦
避免在业务层硬编码 new 实例，把对象创建逻辑外移：
- 用简单工厂根据参数返回对应实现：
NotificationServiceFactory.get("sms") - 用策略模式将不同实现封装为可插拔策略，由上下文按需选择
- Spring 中更推荐用
@Primary或 Profile 控制默认实现，测试环境用 Mock 实现，生产环境用真实实现
关键设计习惯要养成
松耦合不是靠单个语法特性达成的，而是靠持续约束：
- 禁止在 service 层、controller 层出现
instanceof或 if-else 判断实现类型 - 接口方法名体现业务意图，而非技术路径（如用
notify()而非sendBySms()） - 接口粒度适中：一个接口只表达一类能力（如 PaymentProcessor 不应同时包含退款和对账）
- 默认方法慎用：仅用于向后兼容，不作为主要扩展手段；新功能优先新增接口或子接口
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
