网站修改建议电脑编程培训学校哪家好

行为型设计模式之Mediator（中介者）

1）意图

用一个中介对象来封装一系列的对象的交互。中介者使各对象不需要显示的相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

2）结构

其中：

• Mediator (中介者)定义一个接口用于各同事(Colleague)对象通信。
• ConcreteMediator (具体中介者)通过协调各同事对象实现协作行为；了解并维护它的
  各个同事。
• Colleague class (同事类)知道它的中介者对象；每一个同事类对象在需要与其他同事
  通信的时候与它的中介者通信。

3）适用性

Mediator 模式适用于：

• 一组对象以定义良好但是复杂的方式进行通信，产生的相互依赖关系混乱难以理解。
• 一个对象引用其他很多对象并且直接与这些对象通信，导致难以复用该对象。
• 想定制一个分布在多个类中的行为，而又不想生成太多的子类。

/*** @author psd 行为设计模式之中介者模式* 1.  定义一个中介者类，使各同事类对象之间可以相互通信，且不需知道通信的细节。【发给除发送方所有的同事】* 2.  定义同事类，实现中介者类所定义的抽象方法，并持有中介者对象。【发送消息】* 3.  定义抽象中介者类，定义同事类对象之间的通信方法。【接收消息】*/
public class MediatorDemo {public static void main(String[] args) {// 1.  创建中介者对象Concremediator concremediator = new Concremediator();// 2.创建各个同事对象ConcreteColleague1 concreteColleague1 = new ConcreteColleague1(concremediator);ConcreteColleague2 concreteColleague2 = new ConcreteColleague2(concremediator);concremediator.setColleague1(concreteColleague1);concremediator.setColleague2(concreteColleague2);concreteColleague1.sendMessage("南哥是否收到？我是宿州");concreteColleague2.sendMessage("我已收到over，马上给你通地铁");}
}/*** 抽象同事类*/
abstract class Colleague{protected Mediator mediator;
}/*** 同事1*/
class ConcreteColleague1 extends Colleague{public ConcreteColleague1(Mediator mediator) {this.mediator = mediator;}public void sendMessage(String message) {mediator.sendMessage(message, this);}public void receiveMessage(String message) {System.out.println("宿州 收到信息：" + message);}
}/*** 同事2*/
class ConcreteColleague2 extends Colleague{public ConcreteColleague2(Mediator mediator) {this.mediator = mediator;}public void sendMessage(String message) {mediator.sendMessage(message, this);}public void receiveMessage(String message) {System.out.println("南京 收到信息：" + message);}
}/*** 中介者抽象类*/
abstract class Mediator{public abstract void sendMessage(String message, Colleague colleague);
}class Concremediator extends Mediator{private ConcreteColleague1 colleague1;private ConcreteColleague2 colleague2;public void setColleague1(ConcreteColleague1 colleague1) {this.colleague1 = colleague1;}public void setColleague2(ConcreteColleague2 colleague2) {this.colleague2 = colleague2;}@Overridepublic void sendMessage(String message, Colleague colleague) {if (colleague == colleague1){// 同事2 接收到消息colleague2.receiveMessage(message);} else {// 同事1 接收到消息colleague1.receiveMessage(message);}}
}

4.经典应用案例：

1. GUI界面组件交互

场景：表单包含按钮、输入框、下拉菜单等组件，点击按钮需禁用输入框，选择下拉项需更新文本框。
问题：若组件直接相互调用，会形成复杂的网状依赖。
中介者方案：

创建 FormMediator 作为中介者，所有组件通过它通信。

组件事件触发时通知中介者，由中介者调用其他组件的方法。
优势：添加新组件时，只需修改中介者，无需改动现有组件。

2. 聊天室系统（消息中转）

场景：多个用户需要互相发送消息。
问题：用户间直接引用会导致耦合（如 userA.sendMsg(userB, “hello”)）。
中介者方案：

引入 ChatServer 作为中介者，用户只与服务器通信。

用户调用 chatServer.sendMessage(sender, receiver, msg)，由服务器转发。
优势：新增用户时，发送方无需知道所有接收方的存在。

3. 航空管制系统

场景：多架飞机需协调起飞/降落，避免跑道冲突。
问题：飞机间直接通信会导致混乱和安全隐患。
中介者方案：

ControlTower（控制塔）作为中介者，接收飞机的请求，分配跑道并广播状态。

飞机只需向控制塔发送请求，无需与其他飞机交互。
优势：统一管理安全规则，避免资源竞争。

4. 工作流引擎

场景：审批流程涉及多个部门（财务、法务、HR），步骤需按条件流转。
问题：部门间直接调用会导致流程逻辑分散。
中介者方案：

定义 WorkflowEngine 作为中介者，根据当前状态触发下一环节。

部门完成任务后通知引擎，引擎决定下一步执行哪个部门。
优势：流程规则集中维护，部门间无直接依赖。

何时避免使用中介者模式？

交互逻辑简单：对象间只有少量直接通信，引入中介者反而增加复杂度。

中介者成为“上帝对象”：当中介者过度膨胀，承担过多职责时，需考虑拆分。

性能敏感场景：中介者可能成为瓶颈（如高频实时通信）。

模式优势：
降低耦合：对象只需依赖中介者，而非多个其他对象。

简化维护：交互逻辑集中在中介者中，修改更安全。

复用组件：组件不再依赖具体对象，更易独立复用。

喜欢我的文章记得点个在看，或者点赞，持续更新中ing…