如何设计类结构以实现不同类实例间的协同工作？

拆分独立类 vs 设计单个大类的判断依据 #

这绝对不是仅由个人编码偏好决定的选择，核心判断维度如下：

• 单一职责匹配度：一个类只负责一类内聚的核心逻辑。比如示例中飞碟负责移动、俘获目标，库存负责计数与载重计算，生物负责管理自身状态，把这些逻辑全塞进一个大类，后续修改任意规则都要在同一个大文件里翻找，极易引入无关bug。
• 逻辑复用需求：如果某段逻辑需要在多个业务场景复用，就应该拆成独立类。比如Inventory如果后续要给外星基地、货运飞船共用，单独拆分后可以直接引入，不用从飞碟类里硬抠耦合的代码。
• 可测试性要求：独立的小类可以单独编写单元测试，不用初始化一整个超大对象才能验证某一个小功能——比如测试Creature的受惊逻辑，不需要先实例化飞碟、库存等完全无关的对象。
• 变更频率差异：经常迭代修改的逻辑和稳定不变的逻辑要拆分。比如飞碟的移动速度规则可能随版本平衡频繁调整，库存的载重计算规则如果是固定的，拆分开后修改移动逻辑时不会误碰库存代码。
• 团队协作成本：多人协作开发时，按职责拆分为独立类可以让不同开发者负责不同模块，大幅减少同个文件的代码合并冲突。
• 避免过度拆分：如果两部分逻辑永远强绑定、不会单独复用、也不会独立变更，就没必要硬拆成多个类，过度拆分反而会增加代码跳转成本，让逻辑链路更难追踪。

类实例之间的通信实现方案 #

你当前写的示例代码直接引用全局作用域的inventory、cow变量，耦合度极高，一旦实例名修改、或者创建多个飞碟/库存实例，代码会直接报错甚至出现逻辑错误（比如俘获人类时也会触发全局那只牛的受惊逻辑）。常见的可行实现方案有3种：

方案1：构造函数注入依赖（常规场景首选） #

初始化类实例时，把它需要长期持有的依赖实例传入，存为自身属性，完全不依赖全局变量。改造后的可运行示例：

class FlyingSaucer {
  // 初始化时传入依赖的库存实例
  constructor(inventory){
    this.velocity = {x:0, y:0}
    this.isMoving = false
    this.inventory = inventory // 挂载关联实例，后续方法直接调用
  }
  move(){
    if (this.inventory.load < 125){
      this.velocity = {x: 1, y:0}
    } else {
      this.velocity = {x: 0.5, y:0}
    }
    this.isMoving = true
  }
  beamUp(victim){
    if(victim.species === 'cow') {
      this.inventory.cows += 1
    }
    // 注意原代码weight传的是字符串，要转数字再计算
    this.inventory.load += Number(victim.weight)
    // 直接操作传入的victim实例，不要硬编码全局cow
    victim.freakOut()
  }
}
class Inventory{
  constructor(){
    this.cows = 5
    this.humans = 1
    this.load = 0
  }
}
class Creature{
  constructor(species, weight, sounds) {
    this.species = species
    this.weight = weight
    this.sounds = sounds
    this.isScared = false
  }
  freakOut(){
    this.isScared = true
  }
}

// 初始化顺序：先实例化无依赖的基础类
const inventory = new Inventory()
const cow = new Creature('cow', '25', ['moo'])
// 初始化飞碟时注入依赖的库存实例
const saucer = new FlyingSaucer(inventory)
// 俘获操作时把目标生物实例作为参数传入
saucer.beamUp(cow)
saucer.move()

这种方案的优势是依赖关系一目了然，看构造函数就知道当前类依赖哪些其他实例，测试时也可以轻松传入模拟的依赖对象，灵活性很高。

方案2：方法参数临时传参 #

就是示例中beamUp(victim)的写法：只在调用某个方法需要用到对应实例时，把实例作为参数传入，不需要挂到类的长期属性上。适合那种只在单个方法里临时用到、不需要长期持有的依赖——比如被飞碟俘获的生物，飞碟不需要长期存储所有遇到的生物，俘获操作时临时传入即可。

方案3：事件/消息总线（适合多实例松耦合场景） #

如果多个实例之间不需要互相持有引用，只需要在某个状态变更时通知关联方处理，可以用订阅发布模式实现通信。比如飞碟俘获目标时只发送一个abduct事件，库存实例监听事件自动更新载重和计数，被掳走的生物实例监听事件自动触发受惊逻辑，飞碟完全不需要知道库存和生物的存在，耦合度极低，适合复杂的多模块交互场景。极简实现示例：

// 极简事件总线
class EventBus {
  constructor() {
    this.listeners = {}
  }
  on(event, callback) {
    if(!this.listeners[event]) this.listeners[event] = []
    this.listeners[event].push(callback)
  }
  emit(event, payload) {
    if(this.listeners[event]) this.listeners[event].forEach(cb => cb(payload))
  }
}
const globalBus = new EventBus()

class FlyingSaucer {
  constructor(eventBus){
    this.bus = eventBus
    this.velocity = {x:0, y:0}
    this.isMoving = false
  }
  beamUp(victim){
    // 只负责发送事件，不关心后续谁处理逻辑
    this.bus.emit('abduct', victim)
  }
}

class Inventory{
  constructor(eventBus){
    this.cows = 5
    this.humans = 1
    this.load = 0
    // 监听俘获事件，自己更新数据
    eventBus.on('abduct', (victim) => {
      if(victim.species === 'cow') this.cows += 1
      this.load += Number(victim.weight)
    })
  }
}

class Creature{
  constructor(species, weight, sounds, eventBus) {
    this.species = species
    this.weight = weight
    this.sounds = sounds
    this.isScared = false
    // 监听俘获事件，自己是目标就触发受惊
    eventBus.on('abduct', (victim) => {
      if(victim === this) this.freakOut()
    })
  }
  freakOut(){
    this.isScared = true
  }
}

注意：不要为了追求松耦合在简单场景硬上事件机制，事件流过于复杂时反而会提升逻辑追踪的难度，简单交互优先用前两种注入方案。

内容的提问来源于stack exchange，提问作者AlexM