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

時間 2019-11-08

原文原文鏈接

原創做品，能夠轉載，可是請標註出處地址：http://www.cnblogs.com/V1haoge/p/6518603.htmlhtml

　　調停者模式。設計模式

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

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

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

　　下面看看示例代碼：this

調停者接口：Mediatorspa

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、ZhiyuanCcode

 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。

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

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

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

同系列文章：