其他
多个组件通信混乱或紧耦合时用中介者模式集中转发
当多个组件需要相互通信、直接多对多依赖导致混乱或紧耦合时,引入中心 mediator 或 middleware 链统一处理与转发请求。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 48/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 56/100 ×0.15
适用场景
多个组件通信混乱或紧耦合时用中介者模式集通用
解决思路
- 在多个组件之间引入一个中心 mediator;组件不直接互相调用,而是把请求交给 mediator,由 mediator 处理并转发给合适的 handler。
- 在 JavaScript/TypeScript 中,可用对象字面量或函数实现 mediator,不必引入复杂类结构。
- 让每个组件只持有或引用 mediator,不持有其他组件的引用;组件之间互不了解。
- 对需要链式处理的场景采用 middleware 模式:把多个处理函数串联,每个函数可修改 request/response,并通过 next() 调用链中的下一个处理函数。
- Express 示例:用 app.use('/', (req,res,next)=>{ req.headers['test-header']=1234; next(); }) 在根路径请求上添加或修改 header,然后调用 next() 继续。
- Express 示例:可在同一路径注册多个中间件回调,例如第二个回调检查 req.headers['test-header'] 是否存在并调用 next();前一个中间件的修改会在整条链中可见。
- 聊天室示例:创建 ChatRoom 类,提供 logMessage(user, message),在其中生成时间、取 user.getName(),并输出或转发消息。
- 聊天室示例:创建 User 类,构造函数接收 name 和 chatroom;提供 getName();send(message) 只调用 this.chatroom.logMessage(this, message),不直接找其他 User。
- 让所有通信通过中心点流动,以把 many-to-many 关系简化为 components 到 mediator 的关系。
- 通过一个或多个中间件函数跟踪并修改请求对象,直到响应。
- 每次用户命中根路径 endpoint '/' 时,注册的多个中间件回调会依次被调用。
- 用 middleware pattern 简化对象之间的多对多关系,让所有通信流经一个中心点。
适用边界 · 注意事项
- 当两个组件之间直接通信更简单且系统参与者很少时,不要用 mediator。
- 当 mediator 本身膨胀成难以维护的 monolithic god object 时,不要继续使用或不应采用。
- 当事件驱动模式(observer/pub-sub)已经能提供足够解耦且不需要中央协调者时,不要用 mediator。