Can you summarize the following document?
        
  中介者模式是23個周知模式( 即"GoF設計模式")中的一個,GoF設計模式旨在提供重複出現的設計問題的解決方案,以編寫靈活和可複用的物件導向軟體。也就是說,使物件更加易於實現、修改、測試和複用。  中介者設計模式可以解決什麼問題?  使用直接逐個訪問並更新彼此的方式進行物件間的互動靈活性低,因為這種方式使物件彼此間緊密耦合,導致不可能單獨修改類間互動關係本身,而不影響關係中進行互動的類。並且這種方式會令物件變得無法複用,並且難以測試。  由於"緊耦合的物件"過多瞭解其他物件的內部細節,這種物件難以實現、修改、測試以及複用。  中介者模式如何解決上述問題?  物件利用中介者物件與其他物件進行間接互動,中介者物件負責控制和協調互動關係,這麼做可使得物件間"鬆耦合"。這些物件只訪問中介者,不瞭解其他物件的細節。  另見UML類圖和時序圖如下。

  中介者模式是為了“定義一個封裝了物件間互動關係的物件”。這種方式避免了顯式呼叫其他類,促進了類間的鬆耦合,並且使得類間互動關係本身可以單獨修改。客戶類可以使用中介者向其他客戶類傳送資訊,並且通過中介者引發的事件收到資訊。

  

  在以上 UML 類圖中,類 codice_1 和 codice_2 不引用和更新彼此。 相反,它們引用一個通用的 codice_3 介面以實現類間互動的控制和協調(通過codice_4),這使得它們獨立於類間互動的具體細節。 類 codice_5 實現了類 codice_1 和 codice_2之間的互動細節。  上述 UML 時序圖 顯示了這些類之間在執行時的互動過程: 在這個例子中,一個 codice_5 物件 中介,即控制和協調了 codice_1 和 codice_2的物件之間的互動。  如果 codice_1 的物件需要與 codice_2 的物件進行互動,例如更新或者同步狀態, codice_1 呼叫codice_5 物件的 codice_15方法, 以此得到對 codice_1 物件(自己)的改動資訊,並且在 codice_2的物件上執行 codice_18 方法。  此後, codice_2 物件呼叫codice_5 物件的 codice_15方法, 得到對codice_2 (自己)的修改的資料,並且對codice_1 物件呼叫codice_24 方法。

  Mediator - 定義 "Colleague" 物件之間的互動介面。  ConcreteMediator -實現了"Mediator"介面,並且協調 "Colleague"物件之間的互動,知道所有的 "Colleagues" 物件以及其互動目的。  Colleague -定義了通過"Mediator"與其他"Colleague"物件互動的介面。  ConcreteColleague -實現了"Colleague"介面,並且通過它的"Mediator"與其他"Colleague"互動。

  

  中介者模式確保了構件之間的鬆耦合,使得它們不直接呼叫彼此,而是通過中介者呼叫彼此。 在下面的例子中,調解人註冊了所有的構件,然後呼叫了它們的SetState方法。一個聊天室,或者一個需要客戶彼此間每次傳送訊息之後執行動作的系統(對聊天室來說就是每個人之間傳送訊息)可以使用中介者模式。但實際上對聊天室使用中介者模式只在包含遠端功能時有用。 原生的套接字不允許代理回撥(即通過中介者類訂閱的 MessageReceived 事件)。

  在以下示例中,一箇中介者物件控制了三個互相互動的按鈕的狀態,為此它有設定狀態的三個方法:codice_25, codice_26 和 codice_27。 當相應的按鈕被啟用時,對應的方法通過codice_28方法被呼叫。  於是這裡在互動中每個互動的參與者(本例中即按鈕)將自己的行為提交給中介者並且由中介者將這些行為轉給對應的參與者。
在軟體工程領域,中介者模式定義了一箇中介者物件,該物件封裝了系統中物件間的互動方式。 由於它可以在執行時改變程式的行為,這種模式是一種行為型模式 。