Java設計模式之《調停者模式》及應用場景

本文轉載自查看原文 2017-03-08 11:34 2880 調停者模式/ Java/ java/ Mediator/ 設計模式

原創作品，可以轉載，但是請標注出處地址：http://www.cnblogs.com/V1haoge/p/6518603.html

　　調停者模式。

　　我們想象一下這樣的場景：一個系統內部通過許多的類互相之間相互調用來完成一系列的功能，這個系統內部的每個類都會存在至少一次的調用與被調用，多者數不勝數，這種情況下，一旦某個類發生問題，進行修改，無疑會影響到所有調用它的類，甚至它調用的類，可見這種情況下，類與類之間的耦合性極高（體現為太多的復雜的直接引用）。

　　這正是調停者模式的主場，調停者猶如第三方中介一般，將所有的類與類之間的引用都導向調停者類，所有類的請求，一致發向調停者，由調停者再發向目標類，這樣原本復雜的網狀的類關系，變成了簡單的星型類關系，調停者類位於核心，所有其他類位於外圍，指向調停者。如此這般，類與類之間的直接調用耦合被解除（通過統一的第三方來發起調用），某個類發生問題，發生修改，也只會影響調停者，而不會直接影響到簡介發起調用的那些類。

　　下面舉個生活中的實例：一個公司部門，有一個經理來充當調停者，其下的員工充當互相作用的類，這是一個很形象的實例。如果所有職員之間的互動都由職工之間直接進行，一旦某個員工不在，那么必須由此員工操作的事情便無法互動起來，或者某個員工被更換，員工之間不熟悉，也無法進行互動，這樣，經理這個調停者的作用就來了，發起需求的員工將需求告訴經理，經理再找其他員工操作這個需求，明顯的調停者模式。

　　下面看看示例代碼：

調停者接口：Mediator

1 /**
2  * 調停者接口
3  */
4 public interface Mediator {
5     void change(String message,ZhiYuan zhiyuan,String nname);
6 }

職工抽象類：ZhiYuan

 1 /**
 2  * 職員接口
 3  */
 4 public abstract class ZhiYuan {
 5     String name;
 6     private Mediator mediator;
 7     public ZhiYuan(Mediator mediator,String name){
 8         this.mediator = mediator;
 9         this.name = name;
10     }
11     //被調停者調用的方法
12     public void called(String message,String nname){
13         System.out.println(name + "接收到來自"+ nname + "的需求：" + message);
14     }
15     //調用調停者
16     public void call(String message,ZhiYuan zhiyuan,String nname){
17         System.out.println(nname + "發起需求："+ message);
18         mediator.change(message,zhiyuan,nname);
19     }
20 }

具體的調停者：Jingli

 1 /**
 2  * 調停者：經理
 3  */
 4 public class Jingli implements Mediator {
 5     @Override
 6     public void change(String message,ZhiYuan zhiyuan,String nname) {
 7         System.out.println("經理收到" + nname + "的需求：" + message);
 8         System.out.println("經理將" + nname + "的需求發送給目標職員");
 9         zhiyuan.called(message,nname);
10     }
11 }

具體的職員：ZhiyuanA、ZhiyuanB、ZhiyuanC

 1 /**
 2  * 職員A
 3  */
 4 public class ZhiyuanA extends ZhiYuan {
 5     public ZhiyuanA(Mediator mediator, String name) {
 6         super(mediator, name);
 7     }
 8 }
 9 
10 /**
11  * 職員B
12  */
13 public class ZhiyuanB extends ZhiYuan {
14     public ZhiyuanB(Mediator mediator, String name) {
15         super(mediator, name);
16     }
17 }
18 
19 /**
20  * 職員C
21  */
22 public class ZhiyuanC extends ZhiYuan {
23     public ZhiyuanC(Mediator mediator, String name) {
24         super(mediator, name);
25     }
26 }

測試類：Clienter

 1 public class Clienter {
 2     public static void main(String[] args) {
 3         //分配職員與經理
 4         Mediator jingli = new Jingli();
 5         ZhiYuan zhiyuanA = new ZhiyuanA(jingli,"職員A");
 6         ZhiYuan zhiyuanB = new ZhiyuanB(jingli,"職員B");
 7         ZhiYuan zhiyuanC = new ZhiyuanC(jingli,"職員C");
 8         //職員A的需求
 9         String messageA = "這些資料需要B職員操作";
10         zhiyuanA.call(messageA,zhiyuanB,zhiyuanA.name);
11         //職員C的請求
12         String messageC = "這些資料需要B職員簽名";
13         zhiyuanC.call(messageC, zhiyuanB,zhiyuanC.name);
14     }
15 }

執行結果：

職員A發起需求：這些資料需要B職員操作
經理收到職員A的需求：這些資料需要B職員操作
經理將職員A的需求發送給目標職員
職員B接收到來自職員A的需求：這些資料需要B職員操作
職員C發起需求：這些資料需要B職員簽名
經理收到職員C的需求：這些資料需要B職員簽名
經理將職員C的需求發送給目標職員
職員B接收到來自職員C的需求：這些資料需要B職員簽名

　　如上所列，職工A和職工C都需要請求職工B，但是假如他們不認識職工B，那么就將工作需求提交給經理，經理再將工作需求發送給職工B。

　　使用調停者模式貌似要比原本的結構消耗時間，但是卻將需求的發起者與執行者之間的強耦合進行了降低，極大的優化了系統內部的維護工作。

　　調停者模式降低的是系統內部的耦合性，而外觀模式降低的是系統之間的耦合性。

　　調停者模式更加細化，針對的是系統內部類與類之間的強耦合的解除，外觀模式則較為統籌，針對的是整個系統對外的耦合性解除，二者都都有屏蔽復雜性的作用。

同系列文章：

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。