从另一种视角审视 наблюдатель 模式

從傳統的面向物件觀點來看，觀察者 Observer 模式是一種在系統中建立特定物件間通訊關係的設計原則。透過將被觀察者 Observable 與觀察者 Observer 物件間建立一種「被動」的依賴關係，被觀察者能夠在自身狀態改變時，自動通知所有註冊在其底下的觀察者，讓觀察者可以及時獲悉變更並採取適當的應對措施。

具體而言，觀察者 Observer 模式的運作流程如下：

1. 定義抽象的被觀察者介面（interface）：此介面將定義被觀察者必須具有的方法，例如「註冊觀察者」、「取消註冊觀察者」和「通知觀察者」等。
2. 定義抽象的觀察者介面：此介面將定義觀察者必須具有的方法，例如「被通知」等。
3. 建立具體的被觀察者類別：實作被觀察者介面，並提供具體的狀態變更方法。
4. 建立具體的觀察者類別：實作觀察者介面，並提供具體的被通知方法。
5. 透過適當的方法，將觀察者註冊到被觀察者中。
6. 當被觀察者的狀態變更時，呼叫其「通知觀察者」方法，進而呼叫所有註冊觀察者的「被通知」方法。
7. 觀察者於「被通知」方法中執行適當的動作，例如記錄日誌、發送通知或進行進一步的計算。

這種「被動」的依賴關係具有幾個關鍵優點：

1. 解耦合：觀察者 Observer 物件不需要知道被觀察者 Observable 物件的具體實作細節，反之亦然。這種解耦合有助於提高元件間的獨立性，便於日後的維護與擴充。
2. 靈活性：由於觀察者與被觀察者之間的通訊是單向的，開發者可以在系統運行期間動態地註冊或取消註冊觀察者，而無需變更被觀察者的實作。這種靈活性有助於提升系統的可擴充性和可維護性。
3. 擴充性：觀察者 Observer 模式允許在不變更既有架構的前提下，輕易地加入新類別的觀察者。這種擴充性有助於系統因應變更需求，並提供更豐富的 функционал。

然而，觀察者 Observer 模式也並非毫無缺點：

1. 效能影響：在觀察者清單龐大時，呼叫「通知觀察者」方法的效能負擔會隨之提升。開發者必須謹慎評估觀察者數量與系統效能的關係，並適時採取最佳化措施。
2. 執行順序：觀察者的執行順序可能會對系統的運行產生影響。開發者必須在被觀察者中定義明確的執行順序，以確保觀察者能按預期地取得變更通知。
3. 資源管理：觀察者與被觀察者之間的依賴關係會影響資源管理。開發者必須仔細考量觀察者的生命週期，並確保在不再需要時適當取消註冊。

總而言之，觀察者 Observer 模式是一種在系統中建立特定物件間通訊關係的有效設計原則。透過謹慎考量其優缺點，並採取適當的最佳化措施，開發者可以善用此一原則，提升軟體開發的效率與可維護性。

在具體的程式化實作中，開發者可以透過繼承與介面實作的方式，建立被觀察者與觀察者的類別，並透過物件實例建立它們之間的關係。舉例而言，在 Java 中，可以使用 Java 的內建介面與類別，例如 `Observable` 與 `O