実行時の動的UI構築における真理：AddHandlerとAddressOfが支配するメモリとイベントの境界線
業務システムの設計において、Visual Studioのデザイナ（Drag & Drop）は、あくまで「静的なプロトタイプ」に過ぎない。
顧客の要求は常に流動的であり、データベースのスキーマや設定ファイルの定義に基づいて、実行時にコントロールの数、種類、配置、そして振る舞い（Behavior）が決定される場面に、我々プロフェッショナルは幾度となく直面する。
ここで、安易に「コントロールを生成して親コンテナに追加する」だけのコードを書く者は、いずれメモリリークという名の底なし沼に沈むことになる。
本稿では、VB.NETにおける動的フォーム生成の極致、すなわち `AddHandler` と `AddressOf` を用いたイベント配線の設計、およびその背後にあるオブジェクトのライフサイクル管理について、アーキテクトの視点から詳述する。
1. 概念の再定義：DelegateとAddressOfの正体
多くの開発者は `AddressOf` を単なる「メソッドへの参照取得」と考えている。しかし、それは不正確だ。
`AddressOf` は、指定したメソッドのシグネチャに合致するデリゲート（Delegate）のインスタンスを生成するための演算子である。
`AddHandler` は、そのデリゲートを特定のイベントの呼び出しリスト（Invocation List）に登録するプロセスである。このとき、重要なのは「誰が誰を保持しているか」という参照の向きである。
- イベントを発行する側（Source）は、デリゲートを通じてイベントを購読する側（Subscriber）への参照を保持する。
- この参照関係が、オブジェクトのガベージコレクション（GC）を阻害する最大の要因となる。
2. 動的UI構築における「メモリリークの罠」
動的にコントロール（例：`Button`）を生成し、そのイベントをフォームのメソッドに紐付けたとしよう。
“`vb.net
‘ 危険な実装の断片
Dim btn As New Button()
btn.Text = “Dynamic Button”
AddHandler btn.Click, AddressOf OnDynamicButtonClick
Me.Controls.Add(btn)
一見、何も問題はないように見える。しかし、この `btn` が何らかの理由で `Me.Controls.Remove(btn)` されただけでは、不十分な場合がある。
もし、この `btn` が、フォームよりも長い生存期間を持つ「シングルトンな管理クラス」のイベントに紐付けられていた場合、`btn` は決してメモリから解放されない。
「イベントハンドラの解除（RemoveHandler）は、コントロールの破棄（Dispose）と同等の重要度を持つ」
これを忘れることは、プロフェッショナルとして致命的なミスである。
3. 実践的アーキテクチャ：動的コントロール管理クラス
動的なコントロールを生成する場合、個別のコントロールをバラバラに扱うのではなく、そのライフサイクル（生成・配置・イベント配線・破棄）を一括管理する「マネージャークラス」を設計すべきである。
以下に、メモリ効率と保守性を極限まで高めた、動的ボタン生成の実装例を示す。vb.net
”’
”’
Public Class DynamicControlManager
Implements IDisposable
‘ 生成したコントロールを追跡するためのリスト（破棄時に一括処理するため）
Private ReadOnly _managedControls As New List(Of Control)()
Private _isDisposed As Boolean = False
”’
”’
”’ 配置先のコンテナ
”’ コントロールを識別するための一意識別子
Public Sub CreateActionButton(parent As Control, contextId As String)
If _isDisposed Then Throw New ObjectDisposedException(NameOf(DynamicControlManager))
‘ 1. インスタンス化
Dim btn As New Button()
btn.Name = $”btn_{contextId}”
btn.Text = $”Execute {contextId}”
btn.Tag = contextId ‘ 識別子をTagに保持
‘ 2. イベントの動的配線
‘ AddressOfにより、メソッドへのデリゲートを生成し、AddHandlerで登録
AddHandler btn.Click, AddressOf OnDynamicButtonClick
‘ 3. 管理リストへの登録
_managedControls.Add(btn)
‘ 4. UIへの配置
parent.Controls.Add(btn)
End Sub
”’
”’
Private Sub OnDynamicButtonClick(sender As Object, e As EventArgs)
‘ senderを型安全にキャスト
Dim clickedButton = TryCast(sender, Button)
If clickedButton Is Nothing Then Return
‘ Tagからコンテキストを取得
Dim contextId = clickedButton.Tag?.ToString()
‘ ここにビジネスロジックを呼び出す（実際の業務ではインターフェース経由で行うべき）
Console.WriteLine($”[LOG] Context Action Triggered: {contextId}”)
End Sub
”’
”’
Public Sub Dispose() Implements IDisposable.Dispose
If _isDisposed Then Return
For Each ctrl In _managedControls
‘ 重要：イベントハンドラの明示的な解除
‘ これを行わないと、デリゲートがオブジェクトへの参照を保持し続ける可能性がある
‘ ※ 今回の例ではManagerがSourceではないため必須ではないが、
‘ もしManagerのメソッドをControlのイベントに紐付けているなら必須である。
‘ コントロールが持つイベントを解除（必要に応じて）
‘ AddHandlerの対となるRemoveHandlerを呼び出す習慣をつける
‘ RemoveHandler ctrl.Click, AddressOf OnDynamicButtonClick
‘ コントロールの破棄
ctrl.Dispose()
Next
_managedControls.Clear()
_isDisposed = True
End Sub
End Class
### 実装の要諦
1. `Tag` プロパティの活用: 動的に生成されたコントロールが「何のデータに関連しているか」を判別するために、`Tag` に識別子（IDやオブジェクトの参照）を格納する。
2. `IDisposable` の実装: マネージャークラス自体を `IDisposable` にすることで、フォームが閉じられる際に、生成したすべてのコントロールを確実に `Dispose` する。
3. `RemoveHandler` の意識: 今回の例では `Manager` が `Button` のイベントを購読している。もし `Button` が破棄されても、`Manager` が生きている限り、`Button` のデリゲートリストに `Manager` のメソッドが残ることはない（参照の向きが `Button -> Manager` であるため）。しかし、逆に `Manager`（長寿命）が `Button`（短寿命）のイベントを購読する場合は、必ず `RemoveHandler` を行う必要がある。
4. Windows APIとの境界線：低レイヤーへの介入
極めて複雑なUI、例えばサードパーティ製のレガシーなActiveXコントロールや、Win32 APIで制御されるウィンドウを扱う場合、.NETの標準的なイベントモデルでは手に負えないことがある。
そのような場合、`WndProc` をオーバーライドし、Windowsメッセージを直接キャッチする手法が求められる。vb.net
Protected Overrides Sub WndProc(ByRef m As Message)
‘ WM_NOTIFY (0x004E) などのメッセージを監視
Const WM_NOTIFY As Integer = &H4E
If m.Msg = WM_NOTIFY Then
‘ ここでメッセージの中身を解析し、動的に生成したコントロールの
‘ 振る舞いを制御する。これは.NETのイベントハンドラよりも低レイヤーの制御を可能にする。
End If
MyBase.WndProc(m)
End Sub
“`
動的UI構築において、`AddHandler` は「高レイヤーの柔軟性」を提供し、`WndProc` は「低レイヤーの確実性」を提供する。この両輪を使いこなしてこそ、真のアーキテクトである。
結論
動的フォーム生成は、単なる「コントロールの追加」ではない。それは「オブジェクトの生存期間（Lifetime）の設計」そのものである。
- `AddHandler` を使う際は、常に `RemoveHandler` の出口を設計せよ。
- `AddressOf` で渡すメソッドのシグネチャと、メモリ上の参照関係を常に意識せよ。
- 動的な要素が増大するシステムでは、必ず管理クラスを設け、`IDisposable` を通じた決定論的な破棄（Deterministic Disposal）を実装せよ。
これらを守ることで、あなたのシステムは、どれほど巨大な動的UIを構築しようとも、メモリの肥大化に怯えることのない、堅牢なものとなるだろう。
