Java对象协作核心是职责分离与契约交互：按领域切分对象（如User、InventoryChecker）、用接口+组合实现松耦合、事件机制解耦复杂流程、明确定义方法边界。
Java对象间协作的核心，是让每个对象各司其职、职责清晰，通过接口或明确的契约交互，而不是彼此侵入或强耦合。关键不在“怎么调用”，而在“谁该知道什么、谁该负责什么”。
职责分离：先想清楚“谁该做这件事”
一个常见误区是把逻辑堆在某个“万能类”里，比如所有业务都往 Service 类里塞。协作设计的第一步，是按领域职责切分对象：数据封装交给实体类（如 User）、规则判断交给策略类（如 DiscountPolicy）、流程协调交给门面或应用服务（如 OrderService）。每个对象只暴露它“理应对外提供的能力”，隐藏内部细节。
例如下单场景：
- User 负责验证自己是否已实名（自身状态相关逻辑）
- InventoryChecker 负责查库存（独立外部资源校验）
- OrderFactory 负责组装订单对象（创建逻辑集中管理）
- OrderService 只协调这三者，不自己查库也不算折扣（不越权、不代劳）
协作方式：优先用组合 + 接口，慎用继承和静态调用
对象之间要“说话”，得有约定好的语言。接口（interface）就是最轻量、最灵活的契约。比如定义 PaymentProcessor 接口，让 AlipayProcessor、WechatProcessor 各自实现，OrderService 只依赖接口，运行时才决定用哪个。
立即学习“Java免费学习笔记（深入）”；
组合优于继承——不是“我是一个支付处理器”，而是“我持有（has-a）一个支付处理器”。这样替换策略、单元测试打桩、运行时动态切换都更自然。
避免以下协作坏味道：
- 在 A 类里直接 new B()，且 B 无接口抽象（导致无法替换、难以测试）
- 大量使用 static 工具方法跨对象传递状态（破坏封装，隐式依赖）
- 对象之间互相持有对方引用形成环（A 持有 B，B 又持有 A）
消息驱动与事件解耦：适合复杂流程中的松散协作
当多个对象需要响应同一业务动作，但又不想硬编码调用链（比如“下单成功”后要发短信、更新积分、推送消息），可用事件机制。OrderService 发出 OrderPlacedEvent，SmsListener、PointUpdater、PushNotifier 各自监听并处理——彼此完全不知道对方存在。
Java 中可借助 Spring 的 ApplicationEventPublisher + @EventListener，或轻量级事件总线（如 Google Guava EventBus）。重点是：发布者不关心谁接收，接收者不关心谁发布。
边界控制：明确协作的“输入、输出、异常语义”
协作不是“能调通就行”，而是要定义清楚边界。每个公开方法应明确：
- 接受什么参数（建议封装为 DTO 或 Value Object，而非裸字段）
- 返回什么（成功结果？还是 Result
包装体？） - 抛出哪些受检/非受检异常（比如 InventoryException 表示库存不足，属于业务异常；NullPointerException 属于编程错误，不该由调用方捕获）
例如，不写 public void process(Order order)，而写 public ProcessingResult execute(PlaceOrderCommand cmd) —— 命名体现意图，参数封装意图，返回值自带状态和上下文。
基本上就这些。OOP 协作不是堆砌设计模式，而是持续问自己：“这个责任，真的该它扛吗？”、“它需要知道别的对象多少细节？”、“换掉它，会影响多少地方？”。设计得当，代码会自己长出清晰的骨架。
