从模块调用窗体子程序修改控件遇问题，用事件实现后求评估

我开发时遇到以下问题：

• 有一个名为MainForm的窗体，包含ListBox控件（名为EventLog）和向该控件添加项的AddEntry子程序：

Public Sub AddEntry(msg As String)
    EventLog.Items.Add(msg)
End Sub

• 独立模块Routines中有一个foo子程序，用于调用窗体的AddEntry方法：

Module Routines
    Sub foo()
        My.Forms.MainForm.AddEntry(msg)
    End Sub
End Module

• 现象：从窗体内部调用AddEntry功能正常，但从模块调用时无反应也不报错。

按照建议改用事件机制后功能正常，以下是对该实现的评估：

优化后的代码 #

MainForm 代码 #

Public Event AddEntryEv(txt as String)

'事件处理程序
Private Sub AddEntry(txt As String) Handles Me.AddEntryEv
    EventLog.Items.Add(txt)
End Sub

'供外部调用以触发事件的公共子程序
Public Sub Log_AddEntry(txt As String)
    RaiseEvent AddEntryEv(txt)
End Sub

'按钮点击调用模块例程
Private Sub Btn_Click(sender As Object, e As EventArgs) Handles Btn.Click
    RoutineInModule(Me)
End Sub

模块代码 #

Module MainRoutines
    Sub RoutineInModule(ByRef Caller As MainForm)
        Caller.Log_AddEntry("THIS WILL APPEAR IN LISTBOX.")
End Sub

合理性分析 #

优点（该实现是合理且推荐的） #

1. 避免默认实例陷阱：通过传递当前窗体实例Me给模块，彻底解决了原问题中My.Forms.MainForm获取默认实例（与实际显示的窗体不是同一个对象）导致的无效调用问题。
2. 解耦业务与UI：使用事件机制让模块无需直接操作窗体控件，只需通过Log_AddEntry方法触发事件，由窗体自身处理UI更新，符合单一职责原则（模块负责业务逻辑，窗体负责UI渲染）。
3. 接口清晰安全：封装了事件触发的逻辑到Log_AddEntry公共方法，外部无法直接操作事件对象，降低了误用风险。
4. 线程安全基础：由于是从窗体UI线程触发模块调用，回调时仍处于UI线程，确保了控件操作的线程安全性（若后续模块加入异步逻辑，只需在窗体事件处理中增加Invoke判断即可扩展）。

可优化点（非必要，视需求调整） #

如果后续无需扩展多监听者的日志场景，也可以直接将窗体的AddEntry改为公开方法并传递实例调用，但事件机制的扩展性更强——比如后续要同时写入文件日志，只需新增事件处理程序即可，无需修改模块代码。

内容的提问来源于stack exchange，提问作者Jorge Perez