VB.NET インターフェイスの明示的実装：多重継承の衝突を回避し、極限まで洗練されたコンポーネントを構築する技法
VBAやVB6の時代から、私たちは「名前の衝突」という呪縛と戦い続けてきた。COMコンポーネントの参照設定、二重定義されたメソッド、そしてスパゲッティ化したレガシーコードの山。
近代的な.NET環境（.NET Framework / .NET Core）において、このアーキテクチャのジレンマを鮮やかに解決するのが 「インターフェイスの明示的実装（Explicit Interface Implementation）」 である。
今回は、単なる文法解説に留まらない。同一シグネチャを持つ複数インターフェイスの衝突回避、COM相互運用における実務的アプローチ、そしてメモリ効率とガベージコレクション（GC）のライフサイクルまで踏み込んだ、実戦投入のための極限の知見を授けよう。
—
1. なぜ「明示的実装」が必要なのか？（暗黙的実装の限界）
通常、VB.NETでインターフェイスを実装する場合、`Implements`キーワードを使い、クラス内でパブリックなメソッドとして定義する。これを暗黙的実装（Implicit Implementation）と呼ぶ。
しかし、以下のようなシナリオに直面したことはないだろうか？
- 「データ保存」を行う `ISavable` インターフェイス
- 「ログ出力」を行う `ILoggable` インターフェイス
これら双方が、偶然にも `Save()` という全く同じシグネチャ（メソッド名と引数）を持っていた場合、単一のクラスで両方を実装しようとすると、コンパイラはどちらのメソッドを指しているのか迷い、名前の衝突を起こす。
さらに、コンポーネントを外部に公開する際、「クラスの通常の使い方」としては隠蔽したいが、「特定のフレームワークやAPIからのみ呼び出させたい」というカプセル化の要求レベルが高い場面において、暗黙的実装では無力である。
ここで登場するのが 明示的実装 だ。
—
2. 実装パターン：同一シグネチャの衝突を完全制御する
百聞は一見に如かず。実際にコードを見ていこう。
以下の例では、`IFileOperations` と `IDatabaseOperations` が、どちらも `Execute()` というメソッドを持っている。これを1つのクラスで完全に分離して実装する。
Option Strict On
Option Explicit On
Imports System
Namespace EnterpriseArchitecture.Components
‘ — 1. インターフェイスの定義 —
Public Interface IFileOperations
Sub Execute()
End Interface
Public Interface IDatabaseOperations
Sub Execute()
End Interface
‘ — 2. クラスでの「明示的実装」 —
Public Class UniversalExecutor
Implements IFileOperations
Implements IDatabaseOperations
‘ 【重要】明示的実装では Public や Private などのアクセス修飾子を記述してはならない。
‘ 「インターフェイス名.メソッド名」の形式で記述する。
‘ IFileOperations の Execute 実装
Sub ExecuteFile() Implements IFileOperations.Execute
Console.WriteLine(“[File IO] ファイル処理を実行中…”)
‘ ここにファイルI/O特有の処理や、アンマネージドリソースの制御を書く
End Sub
‘ IDatabaseOperations の Execute 実装
Sub ExecuteDatabase() Implements IDatabaseOperations.Execute
Console.WriteLine(“[Database] データベーストランザクションを実行中…”)
‘ ここにDB接続・SQL実行の処理を書く
End Sub
End Class
End Namespace
このコードのアーキテクチャ上の妙味
1. アクセス修飾子の排除: 明示的実装されたメソッドには `Public` をつけてはならない。
2. 外部からの隠蔽: `UniversalExecutor` クラスのインスタンスを直接変数に受けても、`.Execute()` というメソッドはIntelliSenseに出てこないし、呼び出すこともできない。
3. インターフェイス型へのキャストによる呼び出し: このメソッドを呼び出すには、必ず該当のインターフェイス型にアップキャスト（または変数宣言）する必要がある。
Module Program
Sub Main()
Dim executor As New EnterpriseArchitecture.Components.UniversalExecutor
‘ エラーになる！: executor.Execute() は存在しない扱いになる
‘ 正しい呼び出し方（インターフェイス経由）
Dim fileOp As EnterpriseArchitecture.Components.IFileOperations = executor
fileOp.Execute() ‘ 出力: [File IO] ファイル処理を実行中…
Dim dbOp As EnterpriseArchitecture.Components.IDatabaseOperations = executor
dbOp.Execute() ‘ 出力: [Database] データベーストランザクションを実行中…
‘ オブジェクトの解放（後述）
If TypeOf executor is IDisposable Then
DirectCast(executor, IDisposable).Dispose()
End If
End Sub
End Module
—
3. 実務への応用：Windows API連携とリソース管理（IDisposableの明示的実装）
レガシーシステムとの統合や、極限のパフォーマンスが求められる業務アプリケーションにおいて、ハンドルリークは致命傷となる。
ここで、COMオブジェクトやWindows APIのハンドルをラップするコンポーネントを想定し、`IDisposable` の明示的実装を用いた堅牢なライフサイクル管理を構築する。
Imports System.Runtime.InteropServices
Public Class Win32ResourceWrapper
Implements IDisposable
Private _handle As IntPtr
Private _disposed As Boolean = False
Public Sub New(ByVal handleValue As IntPtr)
_handle = handleValue
End Sub
‘ 通常のパブリックメソッド
Public Sub DoWork()
If _disposed Then Throw New ObjectDisposedException(Me.GetType().FullName)
Console.WriteLine(“リソースを使用した処理を実行中… Handle: ” & _handle.ToString())
End Sub
‘ — IDisposable の明示的実装 —
Private Sub Dispose() Implements IDisposable.Dispose
Dispose(True)
GC.SuppressFinalize(Me)
End Sub
‘ 内部の保護されたDisposeパターン
Protected Overridable Sub Dispose(ByVal disposing As Boolean)
If Not _disposed Then
If disposing Then
‘ マネージド資源の解放
End If
‘ アンマネージド資源の解放（例：Win32 APIのハンドル閉局を想定）
If _handle <> IntPtr.Zero Then
‘ 例外を出さないためのAPI呼び出し想定
‘ CloseHandle(_handle)
_handle = IntPtr.Zero
End If
_disposed = True
End If
End Sub
‘ ファイナライザ（デストラクタ）
Protected Overrides Sub Finalize()
Dispose(False)
MyBase.Finalize()
End Sub
End Class
なぜここで明示的実装が活きるのか？
`IDisposable.Dispose` を明示的に実装することで、ビジネスロジック上の通常のパブリックメソッド（例: `Close()` や `Release()`）とインターフェイスの標準仕様（`Dispose()`）を完全に分離できる。これにより、消費者が `Using` ステートメントを使うときだけ `Dispose` が強制され、誤ってビジネスロジック層から不適切なタイミングで破棄メソッドが叩かれるのを防ぐのだ。
—
4. レガシー保守・システム間連携における実践的知見
VBAやVB6のCOMコンポーネント（DLL）を.NETに置き換える際、VB.NETで書かれたクラスライブラリがCOMクライアントから呼び出されるケースは非常に多い。
ここで注意すべきは、明示的実装されたメソッドは、COM相互運用（COM Interop）においてはデフォルトで公開されない（TypeLibにエクスポートされない）という点だ。
- メリット: VBA等のレガシー側から見せたくない内部的な実装詳細を隠蔽し、COMのインターフェイス汚染を防ぐことができる。
- デメリット: もしCOM経由でそのメソッドを叩かせたい場合は、明示的実装ではなく、通常の暗黙的実装（Public宣言）にするか、`ComVisible(True)` 属性と適切な `ClassInterface` 設定を行う必要がある。
レガシーマイグレーションの現場では、「新旧混在期において、VBAから呼ばれるべきインターフェイス」と「.NET内部の最新アーキテクチャでのみ使われるインターフェイス」を切り分けるために、この明示的実装が極めて強力な武器となる。
—
5. チーフアーキテクトからの総括
インターフェイスの明示的実装は、一見すると「マニアックな構文上のテクニック」に思えるかもしれない。しかし、大規模な基幹システム、あるいは複雑なサードパーティ製ライブラリ群を統合するコンポーネント設計において、「名前の衝突を防ぎ、関心を完全に分離する」ための唯一無二の防壁である。
VB.NETの表現力の高さを甘く見てはならない。
コードの意図を厳格にコンパイラに伝え、呼び出されるべき文脈以外からは隠蔽する。この美学こそが、保守性に優れ、10年後も耐えうる堅牢なシステムを構築する唯一の道筋である。
現場のコードに迷ったとき、思い出してほしい。
「隠すべきものは隠し、曝すべきものだけをインターフェイスの契約（Contract）として差し出す」――これこそが、プロフェッショナル・アーキテクトの仕事である。
