23種計模式之 前言 +（5）單例模式、工廠模式、簡單工廠模式、抽象工廠模式、建造者模式、原型模式、+(7)代理模式、裝飾器模式、適配器模式、門面模式、組合模式、享元模式、橋梁模式、+（11）策略模式、責任鏈模式、命令模式、中介者模式、模板模式、迭代器模式、訪問者模式、觀察者模式、解釋器模式、備忘錄模式、狀態(tài)模式 + 設計原則

15-Python與設計模式–中介者模式

一、倉儲管理系統(tǒng)

有一個手機倉儲管理系統(tǒng)，使用者有三方：銷售、倉庫管理員、采購。需求是：銷售一旦達成訂單，銷售人員會
通過系統(tǒng)的銷售子系統(tǒng)部分通知倉儲子系統(tǒng)，倉儲子系統(tǒng)會將可出倉手機數(shù)量減少，同時通知采購管理子系統(tǒng)當
前銷售訂單；倉儲子系統(tǒng)的庫存到達閾值以下，會通知銷售子系統(tǒng)和采購子系統(tǒng)，并督促采購子系統(tǒng)采購；
采購完成后，采購人員會把采購信息填入采購子系統(tǒng)，采購子系統(tǒng)會通知銷售子系統(tǒng)采購完成，
并通知倉庫子系統(tǒng)增加庫存。從需求描述來看，每個子系統(tǒng)都和其它子系統(tǒng)有所交流，在設計系統(tǒng)時，如果直接在一個子系統(tǒng)中集成對另兩個
子系統(tǒng)的操作，一是耦合太大，二是不易擴展。為解決這類問題，我們需要引入一個新的角色-中介者-來將
“網狀結構”精簡為“星形結構”。（為充分說明設計模式，某些系統(tǒng)細節(jié)暫時不考慮，例如：倉庫滿了怎么辦該
怎么設計。類似業(yè)務性的內容暫時不考慮）

首先構造三個子系統(tǒng)，即三個類（在中介者模式中，這些類叫做同事些）：

class colleague():mediator = Nonedef __init__(self,mediator):self.mediator = mediator
class purchaseColleague(colleague):def buyStuff(self,num):print "PURCHASE:Bought %s"%numself.mediator.execute("buy",num)def getNotice(self,content):print "PURCHASE:Get Notice--%s"%content
class warehouseColleague(colleague):total=0threshold=100def setThreshold(self,threshold):self.threshold=thresholddef isEnough(self):if self.total<self.threshold:print "WAREHOUSE:Warning...Stock is low... "self.mediator.execute("warning",self.total)return Falseelse:return Truedef inc(self,num):self.total+=numprint "WAREHOUSE:Increase %s"%numself.mediator.execute("increase",num)self.isEnough()def dec(self,num):if num>self.total:print "WAREHOUSE:Error...Stock is not enough"else:self.total-=numprint "WAREHOUSE:Decrease %s"%numself.mediator.execute("decrease",num)self.isEnough()
class salesColleague(colleague):def sellStuff(self,num):print "SALES:Sell %s"%numself.mediator.execute("sell",num)def getNotice(self, content):print "SALES:Get Notice--%s" % content

當各個類在初始時都會指定一個中介者，而各個類在有變動時，也會通知中介者，由中介者協(xié)調各個類的操作。

中介者實現(xiàn)如下：

class abstractMediator():purchase=""sales=""warehouse=""def setPurchase(self,purchase):self.purchase=purchasedef setWarehouse(self,warehouse):self.warehouse=warehousedef setSales(self,sales):self.sales=salesdef execute(self,content,num):pass
class stockMediator(abstractMediator):def execute(self,content,num):print "MEDIATOR:Get Info--%s"%contentif  content=="buy":self.warehouse.inc(num)self.sales.getNotice("Bought %s"%num)elif content=="increase":self.sales.getNotice("Inc %s"%num)self.purchase.getNotice("Inc %s"%num)elif content=="decrease":self.sales.getNotice("Dec %s"%num)self.purchase.getNotice("Dec %s"%num)elif content=="warning":self.sales.getNotice("Stock is low.%s Left."%num)self.purchase.getNotice("Stock is low. Please Buy More!!! %s Left"%num)elif content=="sell":self.warehouse.dec(num)self.purchase.getNotice("Sold %s"%num)else:pass

中介者模式中的execute是最重要的方法，它根據(jù)同事類傳遞的信息，直接協(xié)調各個同事的工作。
在場景類中，設置倉儲閾值為200，先采購300，再賣出120，

實現(xiàn)如下：

if  __name__=="__main__":mobile_mediator=stockMediator()#先配置mobile_purchase=purchaseColleague(mobile_mediator)mobile_warehouse=warehouseColleague(mobile_mediator)mobile_sales=salesColleague(mobile_mediator)mobile_mediator.setPurchase(mobile_purchase)mobile_mediator.setWarehouse(mobile_warehouse)mobile_mediator.setSales(mobile_sales)mobile_warehouse.setThreshold(200)mobile_purchase.buyStuff(300)mobile_sales.sellStuff(120)

打印結果如下：

PURCHASE:Bought 300 MEDIATOR:Get Info–buy WAREHOUSE:Increase 300
MEDIATOR:Get Info–increase SALES:Get Notice–Inc 300 PURCHASE:Get
Notice–Inc 300 SALES:Get Notice–Bought 300 SALES:Sell 120
MEDIATOR:Get Info–sell WAREHOUSE:Decrease 120 MEDIATOR:Get
Info–decrease SALES:Get Notice–Dec 120 PURCHASE:Get Notice–Dec 120
WAREHOUSE:Warning…Stock is low… MEDIATOR:Get Info–warning
SALES:Get Notice–Stock is low.180 Left. PURCHASE:Get Notice–Stock is
low. Please Buy More!!! 180 Left PURCHASE:Get Notice–Sold 120

二、中介者模式

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

三、中介者模式的優(yōu)點和應用場景

優(yōu)點：
1、減少類與類的依賴，降低了類和類之間的耦合；
2、容易擴展規(guī)模。應用場景：
1、設計類圖時，出現(xiàn)了網狀結構時，可以考慮將類圖設計成星型結構，這樣就可以使用中介者模式了。
如機場調度系統(tǒng)（多個跑道、飛機、指揮塔之間的調度）、路由系統(tǒng)；著名的MVC框架中，其中的C
（Controller）就是M（Model）和V（View）的中介者。

四、中介者模式的缺點

1、中介者本身的復雜性可能會很大，例如，同事類的方法如果很多的話，本例中的execute邏輯會很復雜