我應該使用事件來通知課程還是僅使用回報？

Question

我對今天的活動和代表們毫不留情，爲此，我一直在玩弄體驗酒吧的想法，即遊戲中的進度條。但是，我有一個關於解決我的問題的更好方法的問題 - 它可能和糟糕的設計一樣簡單。讓我給你提供一些細節。

我用ExperienceBar類建模了我的想法。

它包含屬性：

• INT在startValue
• INT CurrentValue的
• INT endValue值

和方法

• 空隙UpdateBar（INT）

UpdateBar將該參數添加到CurrentValue，然後測試是否已達到EndValue。如果超過該金額，EndValue將增加，金額繼續增加。請注意，最初在我看來，它並不關心達到最大可能量的影響，只是最終值增加並且StartValue重置爲零。

另一個名爲Player的類具有ExperienceBar類的屬性。

在我的小演示中，當Player.ExperienceBar.UpdateBar（int）達到EndValue時，它觸發一個由Player類處理的事件。它將Player.Level屬性更新一個。

我剛剛意識到，我可以通過更改UpdateBar（int）來返回類型「true」來實現同樣的目的。此方法可以由Player類進行測試，如果爲true，則Player.Level將增加1。

所以我的問題 - 哪個是最好的實踐方式來處理這個相當具體的情況？作爲這種情況下的一般經驗法則，處理事件是否更好，還是僅僅通過測試return語句來簡化它會更好？ PS：我希望我已經儘量說清楚了，但我可以嘗試澄清是否有人遇到麻煩。我相信我的想法可能會有一些冗餘，但請儘量不要偏離這個問題。我很瞭解他們！謝謝:)

Answer 1

在我看來，沒有最好的方法來做到這一點。有多種方法來實現這個類，這取決於它將如何使用，是更好還是更差。

當您想要爲許多需要了解對象狀態並需要在狀態更改時需要提醒的「客戶端」或「觀察者」實施觀察者模式時使用事件。這適用於只有一個客戶端的退化情況，但更改對象狀態的方法的調用方不是需要知道有關更改的方法。

當狀態只需要被調用者知道時使用返回值，沒有其他類的觀察者。這很簡單，並且將課堂狀態的知識範圍限制爲立即需要了解它的項目。

最後，不要過度設計這個。如果只需要通知調用者，則不要實施事件。如果在某個晚些時候該課程需要被「觀察」，那麼在那個時候實施活動。

Answer 2

那麼...去我，活動是好辦法做到這一點。

但是，如果我來設計應用程序，將下降到一個問題：請問ExperienceBars的事件，當它到達endValue值不斷任何人比類調用UpdateBar別人使用。

如果你正在設計一個組件在很多地方使用（這似乎是目標），答案對我來說似乎是一個幾乎可以肯定是，所以我的回答是使用事件！

/Victor

Answer 3

我會使用事件而不是返回值。爲什麼？原因有兩個：

1. 從UpdateBar返回時返回true意味着什麼？它已更新？ xyz發生了嗎？其他人看着這個（或者你，在路上兩個月）也會好奇。
2. 如果達到限值時應該發生多於一件事情該怎麼辦？然後，必須將所有與這些事情相關的代碼（練級，獲取新項目，無論如何）都綁定到首先用於更新小節的方法中。

我會有一個事件與達到某個級別相關聯，然後「偵聽器」可以相應地作出響應。

Answer 4

這一切都取決於你的組件和你的程序流程的耦合。事件的缺點是你會增加程序的複雜性，因爲很難準確地追蹤任何代碼段可以訂閱你的事件時的執行流程。好處是它允許更靈活和可擴展的設計，因爲任何代碼都可以訂閱你的事件。

因此，如果Player將負責處理與升級相關的所有事情，那麼Player和ExperienceBar之間的緊密耦合是可以的。假設你想公開一個AddIn框架，在這種情況下，你可能想要公開升級到外部插件，在這種情況下，事件更有意義。

個人而言，我有XP是Player的一部分，並有Player暴露出LevelUp事件，但我不沒有看到你的現有代碼知道這是否會爲你和你的框架/域建模是個好主意。

Answer 5

我不認爲有經驗欄觸發一個事件是有意義的 - 在這種情況下，返回值就可以。然後它可以調用Player的LevelUp函數，如果需要，它可以從Player類中觸發OnLevelUp事件。