「とりあえずOpenFileDialog」で消耗するな。堅牢なUIコンポーネント設計の極意
業務自動化ツールを開発していると、必ずぶつかる壁がある。それは「ファイル選択」という最も原始的でありながら、最もバグの温床になりやすいUI処理だ。
「ボタンを押してダイアログを出し、パスを取得する」。この短い処理を、あちこちのフォームでコピペ開発していないか？ もしそうなら、今すぐその手を止めてほしい。ダイアログの表示は、OSのハンドルを掴む危険な操作であり、初期ディレクトリの管理や例外処理を軽視すれば、現場で必ず「予期せぬエラー」を吐くことになる。
今日は、プロのアーキテクトが現場で採用している「安全なダイアログ・ラッパー」の設計思想を伝授する。
—
なぜ「そのまま」使うと危険なのか
標準の `OpenFileDialog` をそのまま実装すると、以下の問題が必ず発生する。
1. 状態の欠落: ユーザーが前回選んだフォルダを記憶せず、毎回デスクトップやルートからやり直させるUIは、業務効率を著しく下げる。
2. 例外ハンドリングの欠如: ネットワークドライブが切断されている場合や、権限のないディレクトリにアクセスしようとした瞬間にアプリはクラッシュする。
3. 検証の甘さ: 選択されたパスが物理的に存在するか、読み込み権限があるかを検証せず、そのまま後続処理（DB登録やファイルI/O）に渡すのは自殺行為だ。
—
プロダクション品質のラッパー：`DialogService` の設計
必要なのは「ダイアログを表示してパスを返すだけ」の機能ではない。「実行可能な状態を保証してパスを返す」ことだ。
以下に、再利用性と堅牢性を両立させたVB.NETの共通クラスを示す。
Imports System.IO
Imports System.Windows.Forms
”’
”’ 状態管理と例外処理をカプセル化する。
”’
Public NotInheritable Class DialogService
‘ 前回選択されたディレクトリを保持（静的変数でセッション中維持）
Private Shared _lastVisitedPath As String = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
”’
”’
Public Shared Function TryGetFilePath(filter As String, ByRef selectedPath As String) As Boolean
Using ofd As New OpenFileDialog()
ofd.Filter = filter
ofd.InitialDirectory = If(Directory.Exists(_lastVisitedPath), _lastVisitedPath, Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments))
If ofd.ShowDialog() = DialogResult.OK Then
‘ 物理的な存在チェック
If File.Exists(ofd.FileName) Then
_lastVisitedPath = Path.GetDirectoryName(ofd.FileName)
selectedPath = ofd.FileName
Return True
Else
MessageBox.Show(“選択されたファイルは存在しません。”, “エラー”, MessageBoxButtons.OK, MessageBoxIcon.Error)
End If
End If
End Using
Return False
End Function
”’
”’
Public Shared Function TryGetFolderPath(ByRef selectedPath As String) As Boolean
Using fbd As New FolderBrowserDialog()
fbd.SelectedPath = _lastVisitedPath
If fbd.ShowDialog() = DialogResult.OK Then
If Directory.Exists(fbd.SelectedPath) Then
_lastVisitedPath = fbd.SelectedPath
selectedPath = fbd.SelectedPath
Return True
End If
End If
End Using
Return False
End Function
End Class
—
この設計の「魂」：3つのポイント
1. `Shared` 変数による状態の継承
`_lastVisitedPath` を `Shared` で保持することで、アプリ起動中、ユーザーが一度ファイルを選んだ場所をダイアログが記憶する。小さな配慮だが、これが「使いやすいツール」と「苦痛なツール」の境界線だ。
2. 「防衛的」なパス検証
`File.Exists` や `Directory.Exists` によるチェックは、UI層とロジック層の間にある「最後の防衛線」だ。ここをすり抜けて、存在しないファイルをDBのパスカラムに保存するような事態は、エンジニアとしてあってはならない。
3. `Using` ステートメントの強制
ダイアログ（`CommonDialog`系）はメモリ消費が大きい。`Using` を使わずに放置すると、連続してダイアログを呼び出した際に予期せぬリソース不足を招く。必ずスコープを限定せよ。
—
実務での活用法
呼び出し側のコードは、これほどまでにシンプルになる。
Private Sub btnSelectFile_Click(sender As Object, e As EventArgs) Handles btnSelectFile.Click
Dim path As String = “”
‘ 成功した時のみ処理を実行するスタイル（ガード句的アプローチ）
If DialogService.TryGetFilePath(“CSVファイル|.csv|すべてのファイル|.”, path) Then
‘ ここで初めてファイルI/Oの重い処理へ移行する
LoadFileToDatabase(path)
End If
End Sub
最後に：自動化エンジニアの矜持
ツールを使い倒す現場のユーザーは、エンジニアが考えるほど「お行儀よく」操作はしてくれない。存在しないファイルを選ぼうとしたり、ネットワーク越しに不安定なストレージを叩いたりする。
「動けばいい」という考えは、開発者自身がメンテナンスの地獄に落ちる未来を予約しているようなものだ。ダイアログ一つをとっても、安全性を担保し、保守性を高める。 その積み重ねこそが、あなたが書くコードの価値を決定づけるのだ。
さあ、今すぐプロジェクト内のダイアログ関連コードをリファクタリングし、真に堅牢なアーキテクチャへと進化させよう。
