总体而言,我无法绕过事件及其处理程序。我正在使用一些使用它们的示例代码,我无法理解为什么使用事件而不是简单地使用sub。我绝对相信我在这里错过了更大的图景。
缩写代码示例:
Public Class MenuEntry
Public Event selected as EventHandler(of EventArgs)
Protected Friend Overridable Sub onSelectEntry(e as EventArgs)
RaiseEvent selected(Me, e)
End Sub
End Class
Public Class Menu
Private menuSelect as New inputAction(Keys.Enter)
Private menuEntry as New List(of MenuEntry)
'keeps track of which menu item we're currently on
Private _selectedEntry as Integer
Public Sub Update()
If menuSelect.evaluate Then
onSelectEntry(_selectedEntry)
End If
Protected Overridable Sub onSelectEntry(ByVal entryIndex as Integer)
menuEntry(entryIndex).onSelectEntry(New EventArgs())
End Sub
End Sub
End Class
Public Class OptionsMenu
Inherits Menu
Private arbitraryOne as Integer
Private arbitraryTwo as Integer
Public Sub New()
Dim entryOne as New MenuEntry(String)
Dim entryTwo as New MenuEntry(String)
AddHandler entryOne.selected, AddressOf entryOneSelected
AddHandler entryTwo.selected, AddressOf entryTwoSelected
MenuEntry.add(entryOne)
MenuEntry.add(entryTwo)
End Sub
Private Sub entryOneSelected(ByVal entryIndex as Integer)
arbitraryOne += 1
End Sub
Private Sub entryTwoSelected(ByVal entryIndex as Integer)
arbitraryTwo += 1
End Sub
End Class
我是对的,我错过了更大的画面。在同一个地方写出所有代码有助于我准确地看到发生了什么。希望我是对的:
事件允许类以非常模糊的方式说“在发生这种情况时做某事”,让创建Object的类定义一个Handler;该行动应该是什么。 Handler可以并且很可能对该类的每个实例都是唯一的。
在我看来,通过索引和枚举,这可能是可以实现的(在基本级别上),但这会变得混乱,并且很快就会编写很多代码。这可能是一种更加灵活和可扩展的处理方式。
无论如何我都会发布这篇文章,希望我能让某人告诉我,我的观察是否正确,还是完全偏离基础,并且它可以帮助那些在这个概念上遇到问题的人他们将脚趾浸入OOP和事件驱动的物体中。
答案 0 :(得分:1)
是的,您的观察是正确的。事件用于让所有感兴趣的人知道发生了某些事情,如果他们感兴趣,他们就可以执行一些额外的操作,这些操作不一定是引发事件的类所固有的。
答案 1 :(得分:1)
在引发事件时能够运行任意代码是一个重要方面。但是它有更大的好处,它大大减少了类之间的耦合。请注意,您的MenuEntry类根本没有对Menu类的引用。您可以完全重新设计Menu类,而无需在MenuEntry类中进行任何更改。这使得代码具有高度可组合性。
技术术语是观察者模式。 Gang of Four book是程序员的必备读物。