継承の深淵：ShadowsとOverridesが分かつ「実行時」と「コンパイル時」の境界線
VB.NETを扱うエンジニア諸君。あなたが書いたそのクラス階層は、本当に「設計」されているだろうか。
多くの開発者がVB.NETの継承において、`Overrides`と`Shadows`を「どちらも親の機能を置き換えるもの」と混同し、その結果、メモリの断片化や予期せぬポリモーフィズムのバグに頭を抱えている。レガシーシステムの保守から、高負荷なWindows API連携までをこなす真のアーキテクトであれば、この二つのキーワードが「メモリ上のどのレイヤーで解決されるか」を完全に掌握していなければならない。
今日は、その本質を叩き込む。
—
1. Overrides：ポリモーフィズムの真髄（動的バインディング）
`Overrides`は、実行時のオブジェクトの型に基づいてメソッドが呼び出される。これがポリモーフィズムの正体だ。
.net
Public MustInherit Class BaseProcessor
‘ 派生クラスで上書きを許可する
Public Overridable Sub Execute()
Console.WriteLine(“Base Logic”)
End Sub
End Class
Public Class SubProcessor
Inherits BaseProcessor
‘ ランタイムは実行時に「このオブジェクトはSubProcessorだ」と判断し、こちらを実行する
Public Overrides Sub Execute()
Console.WriteLine(“Derived Logic”)
End Sub
End Class
極限の知見：
`Overrides`は、仮想メソッドテーブル（vtable）を操作する。ランタイムはメソッドの解決を動的に行うため、数マイクロ秒のオーバーヘッドが発生する。しかし、システム拡張性を考慮すれば、これは受け入れるべきコストだ。逆に言えば、不必要な`Overridable`は付けるな。 メモリと保護の観点から、必要ないメソッドは`NotOverridable`で封印するのが鉄則だ。
—
2. Shadows：コンパイル時の強制隠蔽（静的バインディング）
一方で`Shadows`は、コンパイル時の参照型に基づいてメソッドが決定される。これは「隠蔽」であり「上書き」ではない。
.net
Public Class BaseManager
Public Sub Process()
Console.WriteLine(“Base Process”)
End Sub
End Class
Public Class SubManager
Inherits BaseManager
‘ 基底クラスのProcessを隠蔽し、型に応じた呼び出しを強制する
Public Shadows Sub Process()
Console.WriteLine(“Shadowed Process”)
End Sub
End Class
極限の知見：
ここが致命的な分岐点だ。以下のようにキャストした時、何が起きるか想像できるか？
.net
Dim obj As BaseManager = New SubManager()
obj.Process() ‘ 結果は “Base Process” になる
`Shadows`は、基底クラスの契約を無視する。「基底クラスのメソッドとは全く別のものとして扱う」という宣言だ。レガシーAPIをラップする際、型定義を壊さずに特定環境下でのみ挙動を変えたい時、あるいは外部DLLとの整合性を保つために「親のメソッドを殺したい」時にのみ使用せよ。無秩序な`Shadows`の使用は、後任のエンジニアを地獄へ突き落とす。
—
3. メモリとパフォーマンス：アーキテクトの視点
業務自動化エンジニアとして、メモリ解放についても触れておく。特に`Shadows`を多用した複雑な継承構造は、GC（ガベージコレクション）のルート解析を複雑にする可能性がある。
Windows APIとの連携における注意点
Windows APIを叩く際は、`Marshal`クラスによるメモリ確保が頻発する。`Shadows`でメソッドを隠蔽し、異なるマーシャリングを定義すると、参照の取り違えから`AccessViolationException`を招く。
.net
‘ Windows API呼び出しのラッパー例
Public Class NativeWrapper
Public Shared Sub ShowWindow(hwnd As IntPtr, nCmdShow As Integer)
End Sub
End Class
‘ メモリ管理が必要な場合は、明示的に解放する設計を忘れるな
Public Sub SafeDispose(ByRef obj As IDisposable)
If obj IsNot Nothing Then
obj.Dispose()
obj = Nothing
End If
End Sub
—
結論：どちらを選ぶべきか
- `Overrides`を使うべき時：
- システム設計の段階で「将来的にこの挙動は差し替え可能である」と定義している場合。
- インターフェースベースの設計を行っており、実行時のポリモーフィズムが必須である場合。
- `Shadows`を使うべき時：
- 他社製のDLLなど、修正不可能な基底クラスのメソッドが邪魔をしている場合。
- 基底クラスのメソッド定義をあえて無視し、全く異なるシグネチャを付与して型安全性を担保したい場合。
我々プロフェッショナルは、言語仕様の「機能」を単に使うのではない。その裏側にある、コンパイラがどうメモリを割り当て、ランタイムがどう解決するかを「制御」するのだ。
コードは、常に簡潔に。だが、その裏側にある階層構造は、誰よりも深くあれ。以上だ。
