JAVA设计模式(22) —<行为型>中介者模式(Mediator)

1 定义：

中介者模式(Mediator)
Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each
other explicitly, and it lets you vary their interaction independently.(用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。)

1.1 通用类图：

在中介者模式结构图中包含如下几个角色：

● Mediator（抽象中介者）：它定义一个接口，该接口用于与各同事对象之间进行通信。

● ConcreteMediator（具体中介者）：它是抽象中介者的子类，通过协调各个同事对象来实现协作行为，它维持了对各个同事对象的引用。

● Colleague（抽象同事类）：它定义各个同事类公有的方法，并声明了一些抽象方法来供子类实现，同时它维持了一个对抽象中介者类的引用，其子类可以通过该引用来与中介者通信。

● ConcreteColleague（具体同事类）：它是抽象同事类的子类；每一个同事对象在需要和其他同事对象通信时，先与中介者通信，通过中介者来间接完成与其他同事类的通信；在具体同事类中实现了在抽象同事类中声明的抽象方法。

中介者模式的核心在于中介者类的引入，在中介者模式中，中介者类承担了两方面的职责：

(1) 中转作用（结构性）：通过中介者提供的中转作用，各个同事对象就不再需要显式引用其他同事，当需要和其他同事进行通信时，可通过中介者来实现间接调用。该中转作用属于中介者在结构上的支持。

(2) 协调作用（行为性）：中介者可以更进一步的对同事之间的关系进行封装，同事可以一致的和中介者进行交互，而不需要指明中介者需要具体怎么做，中介者根据封装在自身内部的协调逻辑，对同事的请求进行进一步处理，将同事成员之间的关系行为进行分离和封装。该协调作用属于中介者在行为上的支持。

1.2中介模式的作用

如果在一个系统中对象之间的联系呈现为网状结构，如图20-4所示。对象之间存在大量的多对多联系，将导致系统非常复杂，这些对象既会影响别的对象，也会被别的对象所影响，这些对象称为同事对象，它们之间通过彼此的相互作用实现系统的行为。在网状结构中，几乎每个对象都需要与其他对象发生相互作用，而这种相互作用表现为一个对象与另外一个对象的直接耦合，这将导致一个过度耦合的系统。



图20-4 对象之间存在复杂关系的网状结构

中介者模式可以使对象之间的关系数量急剧减少，通过引入中介者对象，可以将系统的网状结构变成以中介者为中心的星形结构，如图20-5所示。在这个星形结构中，同事对象不再直接与另一个对象联系，它通过中介者对象与另一个对象发生相互作用。中介者对象的存在保证了对象结构上的稳定，也就是说，系统的结构不会因为新对象的引入带来大量的修改工作。



图20-5 引入中介者对象的星型结构

如果在一个系统中对象之间存在多对多的相互关系，我们可以将对象之间的一些交互行为从各个对象中分离出来，并集中封装在一个中介者对象中，并由该中介者进行统一协调，这样对象之间多对多的复杂关系就转化为相对简单的一对多关系。通过引入中介者来简化对象之间的复杂交互，中介者模式是“迪米特法则”的一个典型应用。

1.3 通用代码：

[java] view
plaincopy

public abstract class Mediator {

// 定义同事类

protected ConcreteColleague1 c1;

protected ConcreteColleague2 c2;

// 通过getter/setter方法吧同事类注入进来

public ConcreteColleague1 getC1() {

return c1;

}

public void setC1(ConcreteColleague1 c1) {

this.c1 = c1;

}

public ConcreteColleague2 getC2() {

return c2;

}

public void setC2(ConcreteColleague2 c2) {

this.c2 = c2;

}

// 中介者模式的业务逻辑

public abstract void doSomething1();

public abstract void doSomething2();

}

public class ConcreteMediator extends Mediator {

@Override

public void doSomething1() {

// 调用同事类的方法，只要是public方法都可以调用

super.c1.selfMethod1();

super.c2.selfMethod2();

}

public void doSomething2() {

super.c1.selfMethod1();

super.c2.selfMethod2();

}

}

public abstract class Colleague {

protected Mediator mediator;

public Colleague(Mediator _mediator) {

this.mediator = _mediator;

}

}

public class ConcreteColleague1 extends Colleague {

// 通过构造函数传递中介者

public ConcreteColleague1(Mediator _mediator) {

super(_mediator);

}

// 自有方法 self-method

public void selfMethod1() {

// 处理自己的业务逻辑

}

// 依赖方法 dep-method

public void depMethod1() {

// 处理自己的业务逻辑

// 自己不能处理的业务逻辑，委托给中介者处理

super.mediator.doSomething1();

}

}

public class ConcreteColleague2 extends Colleague {

// 通过构造函数传递中介者

public ConcreteColleague2(Mediator _mediator) {

super(_mediator);

}

// 自有方法 self-method

public void selfMethod2() {

// 处理自己的业务逻辑

}

// 依赖方法 dep-method

public void depMethod2() {

// 处理自己的业务逻辑

// 自己不能处理的业务逻辑，委托给中介者处理

super.mediator.doSomething2();

}

}

注意：
A 在Mediator抽象类中我们只定义了同事类的get/set注入，为什么不使用抽象注入呢？这是因为同事类虽然有抽象，但是没有每个同事类必须要完成的业务方法。当然如果每个同事类都有相同的方法，比如execute 、handler等，那当然注入抽象类，做到依赖倒置。
B 为什么同事类要使用构造函数注入中介者，而中介者注入同事类只使用getter/setter方式呢？因为同事类必须有中介者，而中介者却可以只有部分同事类。

2 优点

减少类间的依赖，把原有的一对多的依赖变成了一对一依赖，同事类只依赖中介者，减少了依赖，当然同时也降低了类间的耦合。

3 缺点

中介者会膨胀得很大，而且逻辑复杂，原本N个对象直接的相互依赖关系转换为中介者和同事类的依赖关系，同事类越多，中介者的逻辑就越复杂。

4 应用场景

类之间的联系是必然的，并非有多个依赖时就要使用中介者模式。中介者模式只适用于多个对象间紧密耦合的情况，紧密耦合的标准是：在类图中出现了蜘蛛网状结构。在这种情况下一定要考虑使用中介者模式，这有利于把蜘蛛网梳理为星型结构，使原本复杂混乱的关系变得清晰简单。

4.1 符合上述紧密耦合标准时使用；

4.2 N个对象之间产生了相互的依赖关系（N>2）；

4.3 多个对象有依赖关系，但是依赖的行为沿不确定或者有发生改变的可能，在这种情况下一般建议采用中介者模式，降低变更引起的风险扩散；

4.4 产品开发。一个明显的例子就是MVC框架，把中介者模式应用到产品中，可以提升产品的性能和扩展性，但是对于项目开发就未必，因为项目是以交付投产为目标，而产品则是以稳定、高效、扩展为宗旨。

生活中的使用情境：

A。机场调度中心；

B。MVC框架；

C。媒体网关；（如MSN通过服务器转发消息，而飞鸽直接使用UDP广播却不是。）

D。各种中介服务；

5 注意事项

5.1 遵循紧密耦合的标准来用中介者模式；
5.2 中介者模式很少用到接口或抽象类，这与依赖倒置原则是冲突的：首先，既然是同事类而不是兄弟类（有相同的血缘），那就说明这些类之间是协作关系，完成不同的任务，处理不同的业务，所以不能在抽象类或接口中严格定义同事类必须具有的方法。因此，如果两个对象不能提炼出共性，就不要刻意去追求两者的抽象，抽象只要定义出模式需要的角色即可。

其次，在一个项目中使用中介者模式可能被多个模块采用，每个中介者所围绕的同事类各不相同，抽象出一个具有共性的中介者也不太可能。
5.3 中介者模式是一种比较常用的模式，也是一种比较容易被滥用的模式。对于大多数的情况，同事类之间的关系不会复杂到混乱不堪的网状结构，因此，大多数情况下，将对象间的依赖关系封装的同事类内部就可以的，没有必要非引入中介者模式。滥用中介者模式，只会让事情变的更复杂。

6 扩展

中介者模式将一个网状的系统结构变成一个以中介者对象为中心的星形结构，在这个星型结构中，使用中介者对象与其他对象的一对多关系来取代原有对象之间的多对多关系。中介者模式在事件驱动类软件中应用较为广泛，特别是基于GUI（Graphical
User Interface，图形用户界面）的应用软件，此外，在类与类之间存在错综复杂的关联关系的系统中，中介者模式都能得到较好的应用。

7 范例

7.1 进销存案例

这三者间已形成了网状关系，加入了一个中介者作为三个模块的交流核心，每个模块之间不再相互交流，要交流就通过中介者进行。每个模块只负责自己的业务逻辑，不属于自己的则丢给中介者来处理，简化了各模块之间的耦合关系，类图如下：



[java] view
plaincopy

/**

* @author cbf4Life cbf4life@126.com I'm glad to share my knowledge with you

* all.

*/

public abstract class AbstractMediator {

protected Purchase purchase;

protected Sale sale;

protected Stock stock;

// 构造函数

public AbstractMediator() {

purchase = new Purchase(this);

sale = new Sale(this);

stock = new Stock(this);

}

// 中介者最重要的方法，叫做事件方法，处理多个对象之间的关系

public abstract void execute(String str, Object... objects);

}

public class Mediator extends AbstractMediator {

// 中介者最重要的方法

public void execute(String str, Object... objects) {

if (str.equals("purchase.buy")) { // 采购电脑

this.buyComputer((Integer) objects[0]);

} else if (str.equals("sale.sell")) { // 销售电脑

this.sellComputer((Integer) objects[0]);

} else if (str.equals("sale.offsell")) { // 折价销售

this.offSell();

} else if (str.equals("stock.clear")) { // 清仓处理

this.clearStock();

}

}

// 采购电脑

private void buyComputer(int number) {

int saleStatus = super.sale.getSaleStatus();

if (saleStatus > 80) { // 销售情况良好

System.out.println("采购IBM电脑:" + number + "台");

super.stock.increase(number);

} else { // 销售情况不好

int buyNumber = number / 2; // 折半采购

System.out.println("采购IBM电脑：" + buyNumber + "台");

}

}

// 销售电脑

private void sellComputer(int number) {

if (super.stock.getStockNumber() < number) { // 库存数量不够销售

super.purchase.buyIBMcomputer(number);

}

super.stock.decrease(number);

}

// 折价销售电脑

private void offSell() {

System.out.println("折价销售IBM电脑" + stock.getStockNumber() + "台");

}

// 清仓处理

private void clearStock() {

// 要求清仓销售

super.sale.offSale();

// 要求采购人员不要采购

super.purchase.refuseBuyIBM();

}

}

中介者Mediator定义了多个private方法，其目的是处理各个对象之间的依赖关系，就是说把原有一个对象要依赖的多个对象的情况移动到中介者的private方法中实现。

但在实际项目中，一般的做法是中介者按照职责进行划分，每个中介者处理一个或多个类似的关联请求。

[java] view
plaincopy

public abstract class AbstractColleague {

protected AbstractMediator mediator;

public AbstractColleague(AbstractMediator _mediator) {

this.mediator = _mediator;

}

}

public class Purchase extends AbstractColleague {

public Purchase(AbstractMediator _mediator) {

super(_mediator);

}

// 采购IBM型号的电脑

public void buyIBMcomputer(int number) {

super.mediator.execute("purchase.buy", number);

}

// 不在采购IBM电脑

public void refuseBuyIBM() {

System.out.println("不再采购IBM电脑");

}

}

public class Stock extends AbstractColleague {

public Stock(AbstractMediator _mediator) {

super(_mediator);

}

// 刚开始有100台电脑

private static int COMPUTER_NUMBER = 100;

// 库存增加

public void increase(int number) {

COMPUTER_NUMBER = COMPUTER_NUMBER + number;

System.out.println("库存数量为：" + COMPUTER_NUMBER);

}

// 库存降低

public void decrease(int number) {

COMPUTER_NUMBER = COMPUTER_NUMBER - number;

System.out.println("库存数量为：" + COMPUTER_NUMBER);

}

// 获得库存数量

public int getStockNumber() {

return COMPUTER_NUMBER;

}

// 存货压力大了，就要通知采购人员不要采购，销售人员要尽快销售

public void clearStock() {

System.out.println("清理存货数量为：" + COMPUTER_NUMBER);

super.mediator.execute("stock.clear");

}

}

public class Sale extends AbstractColleague {

public Sale(AbstractMediator _mediator) {

super(_mediator);

}

// 销售IBM型号的电脑

public void sellIBMComputer(int number) {

super.mediator.execute("sale.sell", number);

System.out.println("销售IBM电脑" + number + "台");

}

// 反馈销售情况,0——100之间变化，0代表根本就没人卖，100代表非常畅销，出1一个卖一个

public int getSaleStatus() {

Random rand = new Random(System.currentTimeMillis());

int saleStatus = rand.nextInt(100);

System.out.println("IBM电脑的销售情况为：" + saleStatus);

return saleStatus;

}

// 折价处理

public void offSale() {

super.mediator.execute("sale.offsell");

}

}

public class Client {

public static void main(String[] args) {

AbstractMediator mediator = new Mediator();

// 采购人员采购电脑

System.out.println("------采购人员采购电脑--------");

Purchase purchase = new Purchase(mediator);

purchase.buyIBMcomputer(100);

// 销售人员销售电脑

System.out.println("\n------销售人员销售电脑--------");

Sale sale = new Sale(mediator);

sale.sellIBMComputer(1);

// 库房管理人员管理库存

System.out.println("\n------库房管理人员清库处理--------");

Stock stock = new Stock(mediator);

stock.clearStock();

}

}

在场景类中增加了一个中介者，然后分别传递到三个同事类中，三个类都具有相同的特性：只负责处理自己的活动（行为），与自己无关的活动就丢给中介者处理。

7.2租房案例

以租房为例，这里中介机构充当租房者与房屋所有者之间的中介者。UML结构图：



首先是抽象中介者:Mediator.java

[java] view
plaincopyprint?





public abstract class Mediator {

//申明一个联络方法

public abstract void constact(String message,Person person);

}

然后是抽象同事对象:Person.java

[java] view
plaincopyprint?





public abstract class Person {

protected String name;

protected Mediator mediator;

Person(String name,Mediator mediator){

this.name = name;

this.mediator = mediator;

}

}

两个具体同事类：HouseOwner.java

[java] view
plaincopyprint?





public class HouseOwner extends Person{

HouseOwner(String name, Mediator mediator) {

super(name, mediator);

}

/**

* @desc 与中介者联系

* @param message

* @return void

*/

public void constact(String message){

mediator.constact(message, this);

}

/**

* @desc 获取信息

* @param message

* @return void

*/

public void getMessage(String message){

System.out.println("房主:" + name +",获得信息：" + message);

}

}

Tenant.java

[java] view
plaincopyprint?





public class Tenant extends Person{

Tenant(String name, Mediator mediator) {

super(name, mediator);

}

/**

* @desc 与中介者联系

* @param message

* @return void

*/

public void constact(String message){

mediator.constact(message, this);

}

/**

* @desc 获取信息

* @param message

* @return void

*/

public void getMessage(String message){

System.out.println("租房者:" + name +",获得信息：" + message);

}

}

具体中介者对象：中介结构、MediatorStructure.java

[java] view
plaincopyprint?





public class MediatorStructure extends Mediator{

//首先中介结构必须知道所有房主和租房者的信息

private HouseOwner houseOwner;

private Tenant tenant;

public HouseOwner getHouseOwner() {

return houseOwner;

}

public void setHouseOwner(HouseOwner houseOwner) {

this.houseOwner = houseOwner;

}

public Tenant getTenant() {

return tenant;

}

public void setTenant(Tenant tenant) {

this.tenant = tenant;

}

public void constact(String message, Person person) {

if(person == houseOwner){ //如果是房主，则租房者获得信息

tenant.getMessage(message);

}

else{ //反正则是房主获得信息

houseOwner.getMessage(message);

}

}

}

客户端：Client.java

[java] view
plaincopyprint?





public class Client {

public static void main(String[] args) {

//一个房主、一个租房者、一个中介机构

MediatorStructure mediator = new MediatorStructure();

//房主和租房者只需要知道中介机构即可

HouseOwner houseOwner = new HouseOwner("张三", mediator);

Tenant tenant = new Tenant("李四", mediator);

//中介结构要知道房主和租房者

mediator.setHouseOwner(houseOwner);

mediator.setTenant(tenant);

tenant.constact("听说你那里有三室的房主出租.....");

houseOwner.constact("是的!请问你需要租吗?");

}

}

运行结果：

房主:张三,获得信息：听说你那里有三室的房主出租.....

租房者:李四,获得信息：是的!请问你需要租吗?

7.3管理页面UI组件管理

Sunny软件公司欲开发一套CRM系统，其中包含一个客户信息管理模块，所设计的“客户信息管理窗口”界面效果图如图20-2所示： 图20-2 “客户信息管理窗口”界面图 Sunny公司开发人员通过分析发现，在图20-2中，界面组件之间存在较为复杂的交互关系：如果删除一个客户，要在客户列表(List)中删掉对应的项，客户选择组合框(ComboBox)中客户名称也将减少一个；如果增加一个客户信息，客户列表中需增加一个客户，且组合框中也将增加一项。 如果实现界面组件之间的交互是Sunny公司开发人员必须面对的一个问题？

Sunny公司开发人员对组件之间的交互关系进行了分析，结果如下：

(1) 当用户单击“增加”按钮、“删除”按钮、“修改”按钮或“查询”按钮时，界面左侧的“客户选择组合框”、“客户列表”以及界面中的文本框将产生响应。

(2) 当用户通过“客户选择组合框”选中某个客户姓名时，“客户列表”和文本框将产生响应。

(3) 当用户通过“客户列表”选中某个客户姓名时，“客户选择组合框”和文本框将产生响应。

于是，Sunny公司开发人员根据组件之间的交互关系绘制了如图20-3所示初始类图：



图20-3 “客户信息管理窗口”原始类图

与类图20-3所对应的框架代码片段如下：

[java] view
plaincopy

//按钮类

class Button {

private List list;

private ComboBox cb;

private TextBox tb;

......

//界面组件的交互

public void change() {

list.update();

cb.update();

tb.update();

}

public void update() {

......

}

......

}

//列表框类

class List {

private ComboBox cb;

private TextBox tb;

......

//界面组件的交互

public void change() {

cb.update();

tb.update();

}

public void update() {

......

}

......

}

//组合框类

class ComboBox {

private List list;

private TextBox tb;

......

//界面组件的交互

public void change() {

list.update();

tb.update();

}

public void update() {

......

}

......

}

//文本框类

class TextBox {

public void update() {

......

}

......

}

分析图20-3所示初始结构图和上述代码，我们不难发现该设计方案存在如下问题：

(1) 系统结构复杂且耦合度高：每一个界面组件都与多个其他组件之间产生相互关联和调用，若一个界面组件对象发生变化，需要跟踪与之有关联的其他所有组件并进行处理，系统组件之间呈现一种较为复杂的网状结构，组件之间的耦合度高。

(2) 组件的可重用性差：由于每一个组件和其他组件之间都具有很强的关联，若没有其他组件的支持，一个组件很难被另一个系统或模块重用，这些组件表现出来更像一个不可分割的整体，而在实际使用时，我们往往需要每一个组件都能够单独重用，而不是重用一个由多个组件组成的复杂结构。

(3) 系统的可扩展性差：如果在上述系统中增加一个新的组件类，则必须修改与之交互的其他组件类的源代码，将导致多个类的源代码需要修改，同样，如果要删除一个组件也存在类似的问题，这违反了“开闭原则”，可扩展性和灵活性欠佳。

由于存在上述问题，Sunny公司开发人员不得不对原有系统进行重构，那如何重构呢？大家想到了“迪米特法则”，引入一个“第三者”来降低现有系统中类之间的耦合度。由这个“第三者”来封装并协调原有组件两两之间复杂的引用关系，使之成为一个松耦合的系统，这个“第三者”又称为“中介者”，中介者模式因此而得名。下面让我们正式进入中介者模式的学习，学会如何使用中介者类来协调多个类/对象之间的交互，以达到降低系统耦合度的目的。
完整解决方案

为了协调界面组件对象之间的复杂交互关系，Sunny公司开发人员使用中介者模式来设计客户信息管理窗口，其结构示意图如图20-7所示：



图20-7 引入了中介者类的“客户信息管理窗口”结构示意图

图20-7只是一个重构之后的结构示意图，在具体实现时，为了确保系统具有更好的灵活性和可扩展性，我们需要定义抽象中介者和抽象组件类，其中抽象组件类是所有具体组件类的公共父类，完整类图如图20-8所示：



图20-8 重构后的“客户信息管理窗口”结构图

在图20-8中，Component充当抽象同事类，Button、List、ComboBox和TextBox充当具体同事类，Mediator充当抽象中介者类，ConcreteMediator充当具体中介者类，ConcreteMediator维持了对具体同事类的引用，为了简化ConcreteMediator类的代码，我们在其中只定义了一个Button对象和一个TextBox对象。完整代码如下所示：

[java] view
plaincopy

//抽象中介者

abstract class Mediator {

public abstract void componentChanged(Component c);

}

//具体中介者

class ConcreteMediator extends Mediator {

//维持对各个同事对象的引用

public Button addButton;

public List list;

public TextBox userNameTextBox;

public ComboBox cb;

//封装同事对象之间的交互

public void componentChanged(Component c) {

//单击按钮

if(c == addButton) {

System.out.println("--单击增加按钮--");

list.update();

cb.update();

userNameTextBox.update();

}

//从列表框选择客户

else if(c == list) {

System.out.println("--从列表框选择客户--");

cb.select();

userNameTextBox.setText();

}

//从组合框选择客户

else if(c == cb) {

System.out.println("--从组合框选择客户--");

cb.select();

userNameTextBox.setText();

}

}

}

//抽象组件类：抽象同事类

abstract class Component {

protected Mediator mediator;

public void setMediator(Mediator mediator) {

this.mediator = mediator;

}

//转发调用

public void changed() {

mediator.componentChanged(this);

}

public abstract void update();

}

//按钮类：具体同事类

class Button extends Component {

public void update() {

//按钮不产生交互

}

}

//列表框类：具体同事类

class List extends Component {

public void update() {

System.out.println("列表框增加一项：张无忌。");

}

public void select() {

System.out.println("列表框选中项：小龙女。");

}

}

//组合框类：具体同事类

class ComboBox extends Component {

public void update() {

System.out.println("组合框增加一项：张无忌。");

}

public void select() {

System.out.println("组合框选中项：小龙女。");

}

}

//文本框类：具体同事类

class TextBox extends Component {

public void update() {

System.out.println("客户信息增加成功后文本框清空。");

}

public void setText() {

System.out.println("文本框显示：小龙女。");

}

}

编写如下客户端测试代码：

[java] view
plaincopy

class Client {

public static void main(String args[]) {

//定义中介者对象

ConcreteMediator mediator;

mediator = new ConcreteMediator();

//定义同事对象

Button addBT = new Button();

List list = new List();

ComboBox cb = new ComboBox();

TextBox userNameTB = new TextBox();

addBT.setMediator(mediator);

list.setMediator(mediator);

cb.setMediator(mediator);

userNameTB.setMediator(mediator);

mediator.addButton = addBT;

mediator.list = list;

mediator.cb = cb;

mediator.userNameTextBox = userNameTB;

addBT.changed();

System.out.println("-----------------------------");

list.changed();

}

}

编译并运行程序，输出结果如下：

--单击增加按钮-- 列表框增加一项：张无忌。 组合框增加一项：张无忌。 客户信息增加成功后文本框清空。 ----------------------------- --从列表框选择客户-- 组合框选中项：小龙女。 文本框显示：小龙女。

中介者与同事类的扩展

Sunny软件公司CRM系统的客户对“客户信息管理窗口”提出了一个修改意见：要求在窗口的下端能够及时显示当前系统中客户信息的总数。修改之后的界面如图20-9所示：



图20-9 修改之后的“客户信息管理窗口”界面图

从图20-9中我们不难发现，可以通过增加一个文本标签(Label)来显示客户信息总数，而且当用户点击“增加”按钮或者“删除”按钮时，将改变文本标签的内容。

由于使用了中介者模式，在原有系统中增加新的组件（即新的同事类）将变得很容易，我们至少有如下两种解决方案：

【解决方案一】增加一个界面组件类Label，修改原有的具体中介者类ConcreteMediator，增加一个对Label对象的引用，然后修改componentChanged()方法中其他相关组件对象的业务处理代码，原有组件类无须任何修改，客户端代码也需针对新增组件Label进行适当修改。

【解决方案二】与方案一相同，首先增加一个Label类，但不修改原有具体中介者类ConcreteMediator的代码，而是增加一个ConcreteMediator的子类SubConcreteMediator来实现对Label对象的引用，然后在新增的中介者类SubConcreteMediator中通过覆盖componentChanged()方法来实现所有组件（包括新增Label组件）之间的交互，同样，原有组件类无须做任何修改，客户端代码需少许修改。

引入Label之后“客户信息管理窗口”类结构示意图如图20-10所示：



图20-10 增加Label组件类后的“客户信息管理窗口”结构示意图

由于【解决方案二】无须修改ConcreteMediator类，更符合“开闭原则”，因此我们选择该解决方案来对新增Label类进行处理，对应的完整类图如图20-11所示：



图20-11 修改之后的“客户信息管理窗口”结构图

在图20-11中，新增了具体同事类Label和具体中介者类SubConcreteMediator，代码如下所示：

[java] view
plaincopy

//文本标签类：具体同事类

class Label extends Component {

public void update() {

System.out.println("文本标签内容改变，客户信息总数加1。");

}

}

//新增具体中介者类

class SubConcreteMediator extends ConcreteMediator {

//增加对Label对象的引用

public Label label;

public void componentChanged(Component c) {

//单击按钮

if(c == addButton) {

System.out.println("--单击增加按钮--");

list.update();

cb.update();

userNameTextBox.update();

label.update(); //文本标签更新

}

//从列表框选择客户

else if(c == list) {

System.out.println("--从列表框选择客户--");

cb.select();

userNameTextBox.setText();

}

//从组合框选择客户

else if(c == cb) {

System.out.println("--从组合框选择客户--");

cb.select();

userNameTextBox.setText();

}

}

}

修改客户端测试代码：

[java] view
plaincopy

class Client {

public static void main(String args[]) {

//用新增具体中介者定义中介者对象

SubConcreteMediator mediator;

mediator = new SubConcreteMediator();

Button addBT = new Button();

List list = new List();

ComboBox cb = new ComboBox();

TextBox userNameTB = new TextBox();

Label label = new Label();

addBT.setMediator(mediator);

list.setMediator(mediator);

cb.setMediator(mediator);

userNameTB.setMediator(mediator);

label.setMediator(mediator);

mediator.addButton = addBT;

mediator.list = list;

mediator.cb = cb;

mediator.userNameTextBox = userNameTB;

mediator.label = label;

addBT.changed();

System.out.println("-----------------------------");

list.changed();

}

}

编译并运行程序，输出结果如下：

--单击增加按钮-- 列表框增加一项：张无忌。 组合框增加一项：张无忌。 客户信息增加成功后文本框清空。 文本标签内容改变，客户信息总数加1。 ----------------------------- --从列表框选择客户-- 组合框选中项：小龙女。 文本框显示：小龙女。

由于在本实例中不同的组件类（即不同的同事类）所拥有的方法并不完全相同，因此中介者类没有针对抽象同事类编程，导致在具体中介者类中需要维持对具体同事类的引用，客户端代码无法完全透明地对待所有同事类和中介者类。在某些情况下，如果设计得当，可以在客户端透明地对同事类和中介者类编程，这样系统将具有更好的灵活性和可扩展
在中介者模式的实际使用过程中，如果需要引入新的具体同事类，只需要继承抽象同事类并实现其中的方法即可，由于具体同事类之间并无直接的引用关系，因此原有所有同事类无须进行任何修改，它们与新增同事对象之间的交互可以通过修改或者增加具体中介者类来实现；如果需要在原有系统中增加新的具体中介者类，只需要继承抽象中介者类（或已有的具体中介者类）并覆盖其中定义的方法即可，在新的具体中介者中可以通过不同的方式来处理对象之间的交互，也可以增加对新增同事的引用和调用。在客户端中只需要修改少许代码（如果引入配置文件的话有时可以不修改任何代码）就可以实现中介者的更换。