代码之家 › 专栏 › 技术社区 › Andrew Weir

我应该使用事件通知类还是只使用返回?

event-handling events c#

Andrew Weir · 技术社区 · 15 年前

今天,我正在全力以赴地参加活动和代表大会,为了做到这一点,我一直在玩弄体验酒吧的想法,那些游戏中的进度酒吧。但我有一个问题,那就是如何更好地解决我的问题——它可能和糟糕的设计一样简单。让我向你提供一些细节。

我用一个经验吧班来模拟我的想法。

它包含属性:

一种方法

updateBar将参数添加到currentValue,然后测试它是否已达到endValue。如果超过了金额,则结束值将增加,金额将继续。注意,在我最初的想法中,它与达到可能的最大数量的效果无关,只是结束值增加,开始值重置为零。

另一个名为player的类具有类experiencebar的属性。

在我的小演示中,当player.experiencebar.updateBar(int)达到endValue时,它会触发一个由player类处理的事件。它逐个更新player.level属性。

我刚刚意识到,只要将updatebar(int)更改为返回类型“true”,就可以实现相同的功能。此方法可以由玩家类测试,如果为真,则玩家等级增加1。

所以我的问题是——哪一种是处理这种相当特殊情况的最佳实践方法?对于这类情况,一般的经验法则是,处理事件更好,还是简单地测试返回语句更好?

附言:我希望我已经尽可能清楚地说明了这一点,但我可以试着澄清是否有人有问题。我相信我的想法可能已经有些多余了,但请不要偏离这个问题。我有点了解他们!谢谢:

5 回复 | 直到 15 年前

Blue Toque 15 年前

在我看来,没有最好的办法。根据类的使用方式,有多种方法来实现类,它们是更好还是更差的适合性。

当您希望为许多“客户机”或“观察者”实现观察者模式时,可以使用事件,这些“客户机”或“观察者”需要知道对象的状态,并且需要在该状态更改时得到警报。这适用于只有一个客户机的退化情况,但更改对象状态的方法的调用方不是需要了解更改的调用方。

当调用方只需要知道状态时,没有类的其他观察者时,使用返回值。这很简单,并且将类状态的知识范围限制为立即需要了解它的项。

最后,不要过度设计这个。如果只需要通知调用者,则不要实现事件。如果在以后某个日期需要“观察”类,那么在该点实现事件。

Victor 15 年前

好。。。到我 ,事件是好的这样做的方法。

然而,如果我要设计这个应用程序,那就归结为一个问题:当ExperienceBars事件达到最终值时,它会不会是ExperienceBars事件? 曾经被调用updatebar的类以外的任何人使用。

如果您正在设计一个在许多地方使用的组件(这似乎是目标),那么对我来说,答案几乎是肯定的。对因此我的答案是 使用事件 !

胜利者

Matt Briggs 15 年前

这一切都取决于组件和程序流的耦合。事件的缺点是,您将增加程序的复杂性,因为当任何一段代码都可以订阅您的事件时,很难准确地跟踪执行流程。好处是它允许更灵活和可伸缩的设计,因为任何一段代码都可以订阅您的事件。

这就是问题所在,如果 Player 将负责处理与调平有关的所有事情,然后在 玩家 和 ExperienceBar 可以。假设您希望公开一个外接程序框架,在这种情况下,您可能希望公开到外部插件的升级,在这种情况下,事件更有意义。

就个人而言,我希望XP是 玩家 并拥有 玩家 揭露一 LevelUp 事件,但我不知道在不看到现有代码的情况下,这是否对您和您的框架/域建模是一个好主意。

Michael Todd 15 年前

我将使用事件而不是返回值。为什么?原因有二:

我将有一个与达到某个级别相关联的事件,然后该事件的“监听者”可以相应地作出响应。

Mike Blandford 15 年前

我认为让体验栏触发一个事件是没有意义的——在这种情况下,返回值是可以的。然后它可以调用player的levelup函数,如果需要,它可以从player类中触发一个onlevelup事件。