0.《设计模式》摘录
- 解决:
把部件之间的关联关系提取出来,定义在另一个类中,这个类就是一个中介器。
新的应用中只要重新定义中介器,其它的GUI部件的代码不需要改变。
1. 问题
国与国之间的关系,就类似于不同的对象与对象之间的关系,这就要求对象之间需要知道其他所有对象,尽管将一个系统分割成许多対象通常可以増加其可复用性,但是对象间相互连接的激増又会降低其可复用性了。
因为大量的连接使得一个对象不可能在没有其他对象的支持下工作,系统表现为一个不可分割的整体,所以,对系统的行为进行任何较大的改动就十分困难了。
如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。
通过中介者对象,可以将系统的网状结构变成以中介者为中心的星形结构。每个具体对象不再通过直接的联系与另一个对象发生相互作用,而是通过’中介者’对象与另一个对象发生相互作用。 中介者对象的设计,使得系统的结构不会因为新对象的引入造成大量的修改工作。
2. 中介者模式
-
定义:
中介者模式(Mediator),用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互 -
结构图:
-
Mediator类:
抽象中介者类,定义了同事对象到中介者对象的接口
abstract class Mediator { public abstract void Send(string message, Colleague colleague); }
-
Colleague类:抽象同事类
abstract class Colleague { protected Mediator mediator; //构造方法,得到中介者对象 public Colleague(Mediator mediator) { this.mediator = mediator; } }
-
ConcreteMediator类: 具体中介者类,它需要知道所有具体同事类,并从具体同事接收消息,向具体同事对象发出命令
class ConcreteMediator extends Mediator { //知道所有的colleague private ConcreteColleaguel colleaguel; private ConcreteColleague2 colleague2; public override void Send(String message,Colleague colleague) { if(colleague == colleague1) { colleague2.Notify(message); } else { colleague1.Notify(message); } } }
-
ConcreteColleague1类:
每个具体同事只知道自己的行为, 而不了解其他同事类的情况,但它们却都认识中介者对象
class ConcreteColleague1 extends Colleague { //继承父类的mediator属性 public ConcreteColleague1(Mediator mediator) { super(); } public void Send(string message) { mediator.Send(message,this); } public void Notify(string message) { Console.WriteLine ("同事 1 得到信息:"+message); } }
ConcreteColleague2类也是类似的
-
客户端:
static void Main(string[] args) { ConoreteMediator m = new ConcreteMediator(); ConcreteColleaguel cl = new ConcreteColleaguel(m); ConcreteColleague2 c2 = new ConcreteColleague2(m); cl. Send("吃过坂了吗?"); c2.Send("没有呢,你打算请客? "); Console.Read(); }
-
3. 优缺点和应用
-
优点
- Mediator的岀现减少了各个Colleague的耦合,使得可以独立地改变和复用各个Colleague类和Mediator
- 由于把对象如何协作进行了抽象,将中介作为一个独立的概念并将其封装在一个对象中, 这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来,也就是站在一个更宏观的角度去看待系统
-
缺点
具体中介者类ConcreteMediator可能会因为ConcreteColleague的越来越多, 而变得非常复杂,反而不容易维护了。
【由于ConcreteMediator控制了集中化,于是就把交互复杂性变为了中介者的复杂性,这就 使得中介者会变得比任何一个ConcreteColleague都复杂】 -
什么时候不要用中介者?
系统岀现了 '多対多’交互复杂的对象群时,不要急于使用中介者模式,而要先反思你的系统在设计上是不是合理。 -
应用:
计算器程序,它上面有菜单控件、文本控件、多个按钮控件和一个Form窗体,每个控件之间不知道对方的存在,比如点击数字按钮要在文本框中显示数字,按照我以前的想法就应该要在Button类中编写给TextBox 类实例的Text属性赋值的代码,造成两个类有耦合,这显然是非常不合理的。但实际情况是它们都有事件机制,而事件的执行都是在Form窗体的代码中完成,也就是说所有的控件的交互都是由Form窗体来作中介,操作各个对象,这的确是典型的中介者模式应用。