? 一組對(duì)象以定義良好但是復(fù)雜的方式進(jìn)行通信。產(chǎn)生的相互依賴(lài)關(guān)系結(jié)構(gòu)混亂且難以理解。
? 一組對(duì)象引用其他很多對(duì)象并且直接與這些對(duì)象通信，導(dǎo)致難以復(fù)用這些對(duì)象。
效果：
? 它將各Colleague 解耦。這有利于各Colleague間的松耦合，可以獨(dú)立的改變和復(fù)用各Colleague類(lèi)和Mediator類(lèi)。
? 簡(jiǎn)化了對(duì)象協(xié)議。用Mediator和各Colleague間的一對(duì)多的交互來(lái)代替多對(duì)多的交互。
? 對(duì)對(duì)象如何協(xié)作大連工業(yè)數(shù)據(jù)采集軟件開(kāi)發(fā)遇到的問(wèn)題進(jìn)行解決，將中介作為一個(gè)獨(dú)立的概念并將其封裝在一個(gè)對(duì)象中，有助于弄清一個(gè)系統(tǒng)中的對(duì)象是如何交互的。
? 控制集中化。中介者模式將交互的復(fù)雜性變?yōu)橹薪檎叩膹?fù)雜性。
致遠(yuǎn)服軟認(rèn)為：http://www.soft8.com.cn/多視圖的另一個(gè)問(wèn)題就是事件的循環(huán)觸發(fā)問(wèn)題，場(chǎng)景如下：事件A發(fā)生->事件A處理函數(shù)->處理過(guò)程中觸發(fā)了事件B->事件B處理函數(shù)->處理過(guò)程中又觸發(fā)了事件A->……。舉一個(gè)簡(jiǎn)單的例子，比如界面上有兩個(gè)文本框，要保證它們的和一直都是100。當(dāng)文本框A輸入30的時(shí)候，文本框B要顯示70。文本框B輸入40的時(shí)候，文本框A要顯示60。我們?cè)谔幚淼谝粋€(gè)輸入事件的時(shí)候需要設(shè)置第二個(gè)文本框的值，而這個(gè)設(shè)值動(dòng)作會(huì)觸發(fā)第二個(gè)文本框的事件處理，它也要設(shè)置第一個(gè)文本框的值……如此循環(huán)。
通常的大連工業(yè)數(shù)據(jù)采集軟件開(kāi)發(fā)遇到的問(wèn)題處理方式有幾種，目的都相同：盡量減少不必要的事件發(fā)送。
? 狀態(tài)真正改變時(shí)才發(fā)事件，狀態(tài)沒(méi)有改變的話(huà)就不發(fā)事件。上面例子中的TextBox 控件如果連續(xù)用相同的參數(shù) 調(diào)用其 SetText，除了第一個(gè)調(diào)用可能會(huì)觸發(fā) TextChanged事件外，后續(xù)的操作都不會(huì)觸發(fā)，因?yàn)樗?Text 并未真的改變。在我們的領(lǐng)域模型中觸發(fā)事件可以遵循相同的Pattern。
? 避免重入。當(dāng)處理大連人力資源管理軟件代碼函數(shù)開(kāi)始事件處理的時(shí)候，把自己置成一個(gè)不同的狀態(tài)，比如“處理中”，事件處理結(jié)束的時(shí)候再置回正常狀態(tài)。當(dāng)在事件處理過(guò)程中觸發(fā)新的事件又導(dǎo)致事件處理函數(shù)被調(diào)用，可以檢查自己是否在“處理中”的狀態(tài)，如果是的話(huà)忽略即可。
? 根據(jù)事件的源頭來(lái)決定是否處理大連工業(yè)數(shù)據(jù)采集軟件開(kāi)發(fā)遇到的問(wèn)題。這需要在事件的上下文中加入額外信 息，比如事件的發(fā)送者sender。微軟的CAB框架允許指定事件的Scope，這樣處理函數(shù)可以只處理自己感興趣 范圍內(nèi)的事件。
掃一掃，微信免費(fèi)咨詢(xún)
