通知另一班級的變化

擁有類Container,Item和Property，只要項目中的某個屬性發生變化，就應該通知容器。通知另一班級的變化

容器是項目的所有者，需要根據其屬性正確管理它們的信息。

我想到了2個選項尚未：

Observer模式。
代理對象。

在我看來，觀察者模式似乎太重了。代理對象可以很好地工作，但是在這種情況下，我會違反DRY原則，因爲我必須將代理中的調用轉發給實際的對象。

需求是，細節對用戶是隱藏的。要求不需要調用一些update_item()函數或類似的函數，即給用戶通知容器的責任，這可能導致使用問題。

來源

2012-07-27 stschindler

在這種簡單的情況下，我沒有看到使用Observer的原因。由於一個Item只能在一個容器中，在一次我只是去給Item引用或指針，以它被放置在容器中。

當Item的一些Property改變它能夠通知它通過的Container該指針

Observer模式在您需要通知許多對象時很有用。

編輯

使用界面，非常簡潔的設計也可能會損害您盡一切簡單的事情。我覺得從zen of Python報價解釋好我的意思：

Special cases aren't special enough to break the rules. //make Interfaces 
Although practicality beats purity. //but not everywhere

所以，你應該在具有純度和實用性的平衡

來源

2012-07-27 15:06:05 Andrew

我用這種方法看到的問題是「Item」變得依賴於「Container」，而「Container」依賴於「Item」。這對C++來說不是問題，但是它表明了一個設計缺陷。一般來說，我傾向於保持孤立。 – stschindler 2012-07-27 15:34:49

@Tank：如果需要，可以通過一些'ContainterInterface'和'ItemInterface'或類似的東西進行通信。它與Observer模式的接口沒有區別。但儘量不要使簡單的事情複雜化） – Andrew 2012-07-27 15:37:42

這是閱讀_Clean Code_等書籍的結果。 ;）當''Item''依賴於''Container''時，我馬上意識到，在單元測試中，老實說，在那裏處理「Container」會感到很奇怪。界面想法對我來說聽起來很不錯，因爲它消除了依賴關係。 – stschindler 2012-07-27 15:43:21

您應該使用最容易的理解和維護，並要求至少格局專門組件的發明。在我工作的環境中（objective-C），觀察者模式就像它得到的那樣簡單。當您的通知請求更改時，它還具有靈活性。

Andrew的答案更簡單 - 對象之間的直接通信不需要代理的發明或通知處理的開銷。但它具有較低的靈活性，如果您將來需要它。

我不確定「太重」是什麼意思。也許你可以解釋一下。

來源

2012-07-27 15:09:15 Jim

「太重」意味着你實際描述的：觀察者模式的開銷。對於內部發生的事情（即用戶永遠不會訂閱對象）。我能想到的最簡單的解決方案是代理，但這非常煩人，因爲它重複了代碼。 – stschindler 2012-07-27 15:37:29

正如前面已經提到的，觀察者在這裏是相當多的矯枉過正，但是這個解決方案非常簡單。你只需要「冒泡」事件。

當一個屬性被改變時，它通知它的父項。
當一個項目被改變時（一個屬性改變的副作用或者對該項目更重要的東西），它通知它的容器/父項）。
當通知容器時，就完成了。如果容器可以嵌套，那麼我猜它可以在必要時將事件引發到它的父容器。

來源

2012-07-27 15:11:31

與Andrew的建議相似的問題：它會向上添加分層依賴關係。這就像一個車輪必須知道這輛車。 ;） – stschindler 2012-07-27 15:35:58

@坦克，但在*感*車輪不需要知道汽車。它只是轉向。這本身就是一個事件。汽車是否傾聽車輪轉向是無關緊要的。我們只是提供信息傳播的機制。 :) – 2012-07-27 15:54:04

這是真的，但是車輪也可以沒有汽車，「Item」不能沒有「Container」，除非你允許沒有父母，但通常情況並非如此。好吧，足夠的汽車愚蠢。 ;） – stschindler 2012-07-27 16:30:46

通知另一班級的變化

回答

相關問題