リアクティブな設定管理：VB.NETとRx.NETで実現する「動的システム」の極意
VBAの`FileSystemWatcher`を使い、泥臭いフラグ管理で設定変更を追う時代は終わった。現代のVB.NET開発、特にミッションクリティカルなWindowsフォームアプリケーションやバックグラウンドサービスにおいて、設定変更をいかに低負荷かつ高信頼に検知するか。
今日は、Rx.NET（Reactive Extensions）を使い、設定ファイルの変更を「ストリーム」として捉える、極限のアーキテクチャを伝授する。
—
1. なぜ「イベントハンドラー」はレガシーなのか
多くのエンジニアが犯す過ちは、`FileSystemWatcher.Changed`イベント内で直接ビジネスロジックを叩くことだ。これでは、ファイル更新の頻発（チャタリング）によるCPUスパイクや、スレッドセーフではないUI操作によるメモリリークを誘発する。
Rx.NETの真骨頂は、「時の流れ」を抽象化し、LINQのような宣言的構文で非同期処理を制御できる点にある。
2. 実装の核心：FileSystemWatcherのリアクティブ化
まずは、ファイルシステムイベントを`IObservable(Of T)`に変換するブリッジを作成する。ここでは、メモリ消費を最小限に抑えるための`IDisposable`の適切な管理が鍵となる。
Imports System.IO
Imports System.Reactive.Linq
Imports System.Reactive.Disposables
Public Class ConfigWatcher
Implements IDisposable
”’
”’
Public Function WatchConfig(filePath As String) As IObservable(Of FileSystemEventArgs)
Dim watcher = New FileSystemWatcher(Path.GetDirectoryName(filePath), Path.GetFileName(filePath))
watcher.EnableRaisingEvents = True
‘ Observable.FromEventPatternを使ってイベントをストリームに変換
Return Observable.FromEventPattern(Of FileSystemEventHandler, FileSystemEventArgs)(
Sub(h) AddHandler watcher.Changed, h,
Sub(h) RemoveHandler watcher.Changed, h
).Select(Function(e) e.EventArgs) _
.Throttle(TimeSpan.FromMilliseconds(500)) _ ‘ 連続する更新を500ms待機して間引く
.Finally(Sub() watcher.Dispose()) ‘ 購読終了時に確実にリソース解放
End Function
End Class
3. シニアエンジニアが意識すべき「メモリの寿命」
VB.NETにおいて`IDisposable`を軽視することは、死を意味する。特に`FileSystemWatcher`は、OSハンドルを占有し続けるため、不要になった際に即座に解放しなければならない。
上記のコードで重要なのは、`.Finally`オペレータだ。購読者が`Dispose`を呼んだ際、あるいはストリームが終了した際に確実に`watcher`を解放する。これが、長期間稼働するシステムにおける「静かなるメモリリーク」を防ぐ唯一の解である。
4. 実戦：設定反映のリアクティブ・パイプライン
次に、通知を受け取った後の「実処理」だ。ここで、設定の再読み込みが競合しないよう、スレッド管理と例外ハンドリングをパイプラインに組み込む。
‘ メイン処理側での購読
Dim disposable = watcher.WatchConfig(“config.json”) _
.ObserveOn(SynchronizationContext.Current) _ ‘ UIスレッドに戻すための同期コンテキスト
.Subscribe(
Sub(e)
‘ ここで設定を再読み込みする
ReloadSettings(e.FullPath)
Console.WriteLine($”設定をリロードしました: {DateTime.Now}”)
End Sub,
Sub(ex) LogError(ex) ‘ エラーハンドリングもストリームの一部
)
‘ アプリ終了時に必ず解放
‘ disposable.Dispose()
5. 伝説的アーキテクトからの助言
この設計を採用することで、以下のメリットが生まれる。
1. チャタリングの完全遮断: `Throttle`オペレータにより、OSが連続発行する不要なイベントを無視できる。
2. 保守性の向上: `AddHandler`を散乱させる必要がなく、設定変更ロジックがひとつの宣言的パイプラインに集約される。
3. 並列制御の容易さ: `Buffer`や`Window`を使えば、例えば「過去5秒間に3回以上更新があった場合のみ警告を出す」といった複雑なロジックも数行で記述できる。
最後に：レガシーとの共存について
もし君が、古いWindows APIを直接叩く必要がある環境にいるなら、`ObserveOn`を駆使し、非同期のリアクティブ処理と、同期的なネイティブ処理を明確に分離せよ。
VB.NETは単なる「古い言語」ではない。適切なライブラリと設計思想を組み合わせれば、最新のC#と何ら遜色のない、いや、VB独自の可読性を持った堅牢なシステムを構築できる。
コードは「動く」だけでなく「美しく、かつ枯れている」べきだ。
次は、君がこのリアクティブな仕組みを自身のアーキテクチャに組み込む番だ。健闘を祈る。
