下面這個假的例子是一個促進投票程序、存盤結果并將其保存到DB的類。我的理解是，這將被認為是一種調解器模式，因為它為物件之間的通信提供了便利，否則這些物件就會被耦合在一起。這是否準確，或者是否有其他模式可以更好地解釋這種行為？謝謝你！
public class StatusPoller
{
public void Poll()
{
foreach(User用戶in users)
{
string accessToken = oAuthClient.Authenticate(user); // Authenticate
List<status> statuses = pollingClient.PollStatus(accessToken); // Poll for status
Store(statuses); //將statuses存盤在DB中。
}
Message.Dispatch(5) //在延遲的情況下發送一條新訊息。
}
}
uj5u.com熱心網友回復：
Kindof,
Mediator模式所要解決的問題是
因此，當 我們正在減少所有這些物件之間的通信的復雜性。
調解器模式被用來降低多個物件或類之間的通信復雜性。這種模式提供了一個中介類，它通常處理不同類之間的所有通信，并通過松散耦合支持代碼的輕松維護。
所以基本上你的 uj5u.com熱心網友回復： 這并不是什么特別的設計模式，這完全可以。它只是一個方法。并非每個方法都需要或應該是一種設計模式。更具體地說，將， 在這樣的設計中， 在這里，沒有一個物件直接與對方對話，所有的（雙向）通信都是通過調解器進行的。
這實際上是一種危險的應用模式，因為正如你從圖片中所猜測的那樣，調解器很容易成為一個神的物件。為了防止業務邏輯滲入調解器并將其責任限制在訊息傳遞上，紀律是必要的。
標籤： 上一篇：無法在生產模式下聯合組件我們想設計可重復使用的程式。
我們想設計可重用的組件，但是潛在的可重用部分之間的依賴關系展示了 "意大利面條代碼 "現象（試圖舀出一個單一的服務，結果是 "所有或沒有的團塊"）。
StatusPoller正在注入和處理其所有的依賴關系時，例如
oAuthClient pollingClient和dbContext（這可能是在Store方法中）StatusPoller是作為一個具體的調解器A --> B轉換為，A --> C --> B不是一個調解器。如果它是，那么每個Web應用程式的服務層都是控制器和DAO之間的調解器。一個調解器會像這樣轉換一個蜘蛛網， A -→ C
↘ ↙ ↘
D ←-→ E
B
A B C
↘ ↓ ↙
M e d i a t o r
↙ ↑↓
D E