設計模式之中介者模式

　　在設計代碼結構的時候，我們經常會遇到這樣的情況，按照需求我們有多個類要實現，而這多個類之間互相存在著業務關系。如果我們不假思索地直接把這些類實現的話，那么不但代碼邏輯顯得很混亂，而且耦合性很高，牽一發而動全身，很可能一處的代碼需要修改就導致各個類中的代碼都需要修改，這種“連坐”是我們需要盡力避免，中介者模式就是用來解決這類問題的。

　　中介者模式的定義：用一個中介者對象封裝一系列的對象交互，中介者使各對象不需要顯示地相互作用，從而使耦合松散，而且可以獨立地改變它們之間的交互。下面先盜個圖：

抽象中介者Mediator：定義好同事類對象到中介者對象的接口，用于各個同事類之間的通信。一般包括一個或幾個抽象的事件方法，并由子類去實現。

中介者實現類ConcreteMediator：從抽象中介者繼承而來，實現抽象中介者中定義的事件方法。從一個同事類接收消息，然后通過消息影響其他同時類。

抽象同事類Colleague：同時類的抽象，具有同事類的共同特征。

同事類ConcreteColleague：如果一個對象會影響其他的對象，同時也會被其他對象影響，那么這兩個對象稱為同事類。在類圖中，同事類只有一個，這其實是現實的省略，在實際應用中，同事類一般由多個組成，他們之間相互影響，相互依賴。同事類越多，關系越復雜。并且，同事類也可以表現為繼承了同一個抽象類的一組實現組成。在中介者模式中，同事類之間必須通過中介者才能進行消息傳遞。

　　我們拿寶信MES的產供銷一體化做個簡化模型：現在有生產、庫存和銷售三個類，假如平時每次生產10個，當庫存大于等于100個，就停止生產，銷售的量達到庫存的一半就要生產雙倍，這樣一來三個類互相有關聯，事實上寶信的產供銷一體化不僅有采購庫存銷售，還有生產、資材、運輸、財務等等模塊，這些模塊互相都有關聯，如果直接做的話，估計能麻煩死，為了說明中介者模式，還是用上面說的三個類。

static class Maker {
	
	public Maker() {
	}
	public static void make() {
		if(Stock.goods>=100){
                     return;
                }
                Stock.goods+=10;
		System.out.println("生產了10件產品");
	}
}
static class Stock {
	public static int goods;
	public Stock() {
	}
	public void clear(){
        }
}
class Sale extends Colleague {
        public Sale() {
        }
	public void sale(int i) {
               if(i>=Stock.goods){
                   Maker.make();
                   Maker.make();
               }
               Stock.goods-=i
 	}
	
}

這樣三個類相互糾纏，修改點需求就會比較麻煩，下面用中介者來調度

abstract class Mediator {
	protected Maker maker;
	protected Stock stock;
	protected Sale sale;
	public Mediator() {
		maker = new Maker(this);
		stock = new Stock(this);
		sale = new Sale(this);
	}
	public abstract void excute(String str, Object...obj);
}
class ConcreteMediator extends Mediator {

	@Override
	public void excute(String str, Object... obj) {
		if(str.equals("maker.make")) {
			this.make();
		}
		if(str.equals("stock.clear")) {
			this.clear();
		}
		if(str.equals("sale.sale")) {
			this.sale((int)obj[0]);
		}
	}

	private void sale(int i) {
		if(i>=super.stock.goods){
            this.make();
            this.make();
        }
        super.stock.goods-=i;
	}

	private void clear() {
		super.stock.goods = 0;
		System.out.println("清倉");
	}

	private void make() {
		if(super.stock.goods>=100){
            return;
       }
		super.stock.goods+=10;
		System.out.println("生產了10件產品");
	}
	
}
abstract class AbstractColleague {
	protected Mediator mediator;
	public AbstractColleague(Mediator _mediator) {
		this.mediator = _mediator;
	}
}
class Maker extends AbstractColleague {
	public Maker(Mediator _mediator) {
		super(_mediator);
	}
	public void make() {
		super.mediator.excute("maker.make");
	}
}
class Stock extends AbstractColleague {
	public int goods;
	public Stock(Mediator _mediator) {
		super(_mediator);
	}
	public void clear() {
		super.mediator.excute("stock.clear");
	}
}
class Sale extends AbstractColleague {
	public Sale(Mediator _mediator) {
		super(_mediator);
	}
	public void sale(int i) {
		super.mediator.excute("sale.sale",i);
	}
}

　　這樣就把方法都交給中介者去調度了，而各個同事類只需要通知中介者去執行對應方法就可以了，類似于星型結構，高內聚低耦合。當需求改動時，在中介者實現類中修改對應方法就可以，符合迪米特原則。

posted @ 2018-01-03 14:30 AI架構牧羊人閱讀(212) 評論(0) 收藏舉報

刷新頁面返回頂部

架構牧羊人

設計模式之中介者模式

公告