在试图找出我们以前的开发人员编写的一些代码时正在考虑这个问题。试图追踪程序的控制是如何发生的,这让我想起了 BASIC 的糟糕旧时代,在那个时代,程序的执行路径几乎不明显。这更像是事件滥用的症状,还是观察者模式存在结构性问题?
5 回答
像任何技术一样,事件可能会被错误地使用和滥用。但是,由于您没有给出任何问题示例,我们几乎不可能说出您在说什么。
一般来说,没有。事件不是 OO 的等价物GOTO
,它们通常也不是问题。我所知道的观察者模式也没有任何结构性问题。但虐待可能发生在任何事情上。
GOTO 不好的原因有很多,但最大的原因之一是它是程序流的转移,而不仅仅是子程序的执行。当您使用 goto 时,程序执行不会返回到 goto 调用完成后的点(或在异步事件的情况下启动后)。程序流被永久转移到新的执行点。更糟糕的是,它可以将执行转移到任何地方,包括其他控制结构或其他功能内部。
事件根本没有这些特征,只不过是具有对象感知和发布/订阅功能的函数指针。(好吧,还有很多,但这是它们的基本用法)
不,不是。后藤是……啊……我怕猛禽……
事件只不过是一个被一个一个调用的代表列表。铁:
-> Click Event gets called
-> List of associated Event-Handlers
-> Calls every Event-handler/Delegate in the List
我在事件中看到的最糟糕的事情是在一个事件中调用多个其他事件。与我一起工作的一位同事经常这样做。我认为这可能是一种难以遍历的情况,但它仍然比 GOTO 更具可读性。
要回答您的问题,事件不是 GOTO 的 OO 等价物,因为 GOTO 本身是一个保留字。事件是不同的,事件遵循火而忘记范式,其中 GOTO 在代码中“被解雇但按程序处理”。使用 GOTO 会导致滥用,从而导致意大利面条式代码。尽管如此,可以使用 GOTO 的唯一时间是在方法/或功能范围内的错误恢复情况下。事件可以被许多接收者使用,而 GOTO 只能被一个接收者使用。
使用诸如PostSharp之类的 AOP 框架可能是值得的,您可以在其中将 AOP 在运行时注入到您的代码中,以便查看事件的流程和跟踪,以帮助更好地理解代码。
希望这会有所帮助,最好的问候,汤姆。
事件不等同于 GOTO。情况可能更糟。当程序员不得不在他们的代码中编写 GOTO 时,他们感觉很糟糕。有了事件,就不一样了。人们在使用 Event 时会感到完美、现代和酷。我最近花了一些时间试图了解一个包含大约 100 个类、400 个事件和 300 个处理程序注册的系统。我理解你的痛苦。使用 Event,将看似独立的对象连接起来太容易了。事件可以绕过或隐藏对象和引用的逻辑关系,使整个系统很难理解。