减少类间耦合的核心是依赖抽象而非具体实现，通过接口隔离、依赖注入（推荐构造器注入）、事件驱动和单一职责原则，结合组合优于继承，实现松耦合设计。
减少类之间的耦合，核心是让类只依赖抽象，不依赖具体实现；通过接口隔离、依赖注入和单一职责等手段，把“谁用谁”变成“谁用谁的契约”。
用接口或抽象类定义契约，而非具体类
当一个类需要调用另一个类的功能时，不要直接 new 具体实现类，而是面向接口编程。比如订单服务需要发短信，就依赖 SmsSender 接口，而不是 AliyunSmsSender 或 TencentSmsSender。
- 定义 SmsSender 接口，声明 send(String phone, String content)
- 多个实现类（如 AliyunSmsSender、MockSmsSender）各自实现该接口
- 订单类中只持有 SmsSender 类型的字段，运行时由外部传入具体实现
依赖注入代替主动创建，把控制权交给外部
类内部不自己 new 对象，而是通过构造函数、setter 或方法参数接收依赖。这样便于替换实现、单元测试，也显式表达了“我需要什么”。
- 推荐构造器注入：在创建订单服务时，把 SmsSender 实例传进去
- 避免在业务方法里 new 实现类——那是强耦合的典型信号
- Spring 等框架能自动完成注入，但原理要自己理解：解耦的关键不在框架，而在设计意图
引入中介或事件机制，避免类之间直接调用
当多个类存在一对多或跨层交互（如订单创建后要通知库存、积分、物流），不要让订单类直接调用其他服务，改用事件发布/订阅模式。
立即学习“Java免费学习笔记（深入）”；
- 订单服务发布 OrderCreatedEvent 事件
- 库存服务、积分服务等作为监听者，各自响应，互不知晓对方存在
- 事件总线（如 Spring 的 ApplicationEventPublisher）承担中介角色，降低直接依赖
合理划分边界，小而专注的类更易解耦
一个类职责越杂，就越容易和各种其他类产生联系。把大类拆成小类，每个只做一件事，自然减少了被依赖和依赖的范围。
- 比如“用户中心”类，可拆为 UserAuth（登录注册）、UserProfile（资料管理）、UserAddress（地址维护）
- 每个子类只暴露明确接口，内部实现可独立演进
- 组合优于继承：用组合方式把功能拼起来，比用继承拉长类链路更灵活、更低耦合
