継承の深淵：ShadowsとOverrides、その境界線にある「設計の意思」
VB.NETを扱うエンジニア諸君、日々レガシーなCOMコンポーネントの断末魔と、最新の.NET Coreの静寂な間で格闘していることだろう。
VB.NETにおける継承の文法には、一見似て非なる二つのキーワードが存在する。`Shadows`と`Overrides`だ。これらは単なる構文の使い分けではない。メモリ上の仮想テーブル（VTable）の扱い、そしてシステム全体の「多態性（ポリモーフィズム）」という契約を左右する重大な設計上の選択である。
今回は、この両者の本質的な違いを、メモリ最適化とシステム設計の観点から解剖する。
—
1. Overrides：契約とポリモーフィズムの体現
`Overrides`を使用するということは、基底クラスとの間に「私はこのメソッドの正当な継承者である」という契約を結ぶことに他ならない。
Public Class BaseSystem
‘ Overridableを明示することで、派生先での再定義を許可する（仮想テーブルへの登録）
Public Overridable Sub ExecuteProcess()
Console.WriteLine(“基底処理：標準的なDB接続”)
End Sub
End Class
Public Class DerivedSystem
Inherits BaseSystem
‘ 基底クラスの振る舞いを「上書き」し、ポリモーフィズムを実現する
Public Overrides Sub ExecuteProcess()
Console.WriteLine(“派生処理：最適化されたコネクションプール利用”)
End Sub
End Class
なぜOverridesなのか？
`Overrides`は、ランタイムがインスタンスの型を問わず、そのオブジェクトの真の性質（派生型）に基づいてメソッドを呼び出すことを可能にする。これはメモリ効率を追求する際、「インターフェースを介した疎結合な設計」を強制する強力な武器となる。
—
2. Shadows：メモリの断絶と破壊的隠蔽
対して`Shadows`は、基底クラスのメソッドを無視し、完全に「別のもの」として名前空間を奪い取る行為だ。これはポリモーフィズムの鎖を断ち切る。
Public Class LegacyModule
Public Sub Connect()
‘ Windows API (Win32 API) を直接叩くような低レイヤー処理
End Sub
End Class
Public Class ModernModule
Inherits LegacyModule
‘ 基底のConnectとは全く別のロジックを強制的に割り込ませる
Public Shadows Sub Connect()
‘ 新規のAPI連携ロジック
End Sub
End Class
Shadowsがもたらす「意図せぬバグ」
`Shadows`を使用すると、参照型の変数の型によって呼び出されるメソッドが決定する。
- `Dim obj As LegacyModule = New ModernModule()`
- この場合、`obj.Connect()`を呼ぶと、なんと`LegacyModule`側のメソッドが動く。
シニアエンジニアとして警告しておく。`Shadows`は「基底クラスを書き換えられない」という制約下で、やむを得ず名前の衝突を回避するために使う最後の手段だ。多態性を期待するコードでこれを使うと、デバッグは地獄と化す。
—
3. 実務における極限の知見：メモリとAPI呼び出し
レガシーなWindows APIをラップするクラスを設計する際、これらの違いは決定的な差を生む。
メモリ最適化とIDisposableの継承
API呼び出しを伴うクラスでは、`Finalize`や`Dispose`の管理が命綱だ。基底クラスで`IDisposable`を実装している場合、`Overrides`を適切に使わなければ、派生クラスで確保したアンマネージドリソースが解放されず、メモリリークの温床となる。
‘ 良い設計の例：Overridesを活用したリソース解放の継承
Protected Overrides Sub Dispose(disposing As Boolean)
If disposing Then
‘ マネージドリソースの解放
End If
‘ アンマネージドリソース（Windows APIのハンドル等）をここで解放
MyBase.Dispose(disposing)
End Sub
なぜ「設計の意思」が重要なのか
もし君が、既存のVB6からの移植案件で、`Shadows`を乱用して継承関係をねじ曲げれば、それは数年後の保守担当者への「時限爆弾」となる。
- Overridesを選択すべき時: クラスの機能拡張、フレームワークのフックポイントの作成。
- Shadowsを選択すべき時: 外部ライブラリ（修正不能なソース）のメソッド名と衝突してコンパイルが通らない時、あるいは意図的に基底クラスの機能を隠蔽し、型安全性（静的解決）を強制したい時。
—
結びに：伝説のアーキテクトからの助言
技術とは、単にコードを書くことではない。「このメソッドを呼び出す人間が、どのクラスの型で参照しているか」というランタイムの挙動を、脳内でアセンブラレベルまでシミュレートすることだ。
VB.NETの継承は、C#よりも冗長かもしれない。しかし、その冗長さこそが、設計者の「意思」をコンパイラに伝えるためのパスポートなのだ。
`Shadows`を軽率に使うな。`Overrides`の責任を放棄するな。
諸君が構築するシステムが、10年後も堅牢に稼働し続けることを願っている。
