【VB.NET極意】ShadowsとOverridesの境界線：継承の闇を制御し、堅牢なクラス階層を構築せよ
現場で「なぜか期待したメソッドが呼ばれない」というバグに遭遇したことはないだろうか？
VB.NETにおける`Shadows`と`Overrides`。この二つのキーワードは、単なる構文の違いではない。それは「オブジェクト指向という設計思想を、貴方がどのように制御したいか」という意志の表明である。
多くのエンジニアがこの違いを曖昧にしたままコードを書き、結果としてデバッグ地獄に陥る。本稿では、伝説的な自動化エンジニアの視点から、この二つの決定的な違いと、保守性の高いプロダクションコードの書き方を伝授する。
—
1. 概念の核心：ポリモーフィズムの「意志」
まず、結論から言おう。
- `Overrides`（上書き）： 「契約」である。基底クラスが提供する機能の実装を置き換える。ポリモーフィズムの恩恵をフルに受け、実行時のインスタンス型に従ってメソッドが選択される。
- `Shadows`（隠蔽）： 「遮断」である。基底クラスのメンバを無かったことにする。ポリモーフィズムを意図的に断ち切り、型に応じた動作を強制する。
比較表：挙動の決定的な違い
| 特徴 | Overrides | Shadows |
| :— | :— | :— |
| 設計思想 | 拡張と特化（ポリモーフィズム） | 遮断と独立（名前の衝突回避） |
| 実行時の振る舞い | インスタンスの型に依存する | 参照（変数）の型に依存する |
| 基底クラスへのアクセス | `MyBase`で呼び出し可能 | `MyBase`で呼び出し可能（ただし見かけ上は隠れる） |
—
2. 現場でなぜ「Shadows」が危険視されるのか
`Shadows`が多用される現場は、設計が破綻している可能性が高い。
例えば、基底クラスに`UpdateDatabase()`というメソッドがあるとする。派生クラスで`Shadows`を使って同名メソッドを定義すると、`BaseClass`型の変数に派生クラスを代入した瞬間、呼び出されるメソッドが「基底クラスのもの」に入れ替わる。
これは、「型変換（キャスト）によって挙動が変わる」という悪夢を誘発する。業務自動化ツールにおいて、データベース更新のタイミングが変数型によって変わる仕様など、保守担当者にとっては呪い以外の何物でもない。
—
3. 実践：保守性を最大化するプロダクションコード例
堅牢な設計とは、誰が読んでも「何を意図しているか」が明確なコードである。
推奨される設計：Overridesの活用
業務ロジックの共通化には、`MustInherit`（抽象クラス）と`Overrides`を組み合わせてテンプレートメソッドパターンを適用せよ。
Public MustInherit Class DataProcessor
‘ テンプレートメソッド：処理の流れを固定する
Public Sub Execute()
‘ 共通前処理
Logger.Info(“処理開始”)
‘ 派生クラスで実装を強制（契約）
ProcessCore()
‘ 共通後処理
Logger.Info(“処理完了”)
End Sub
‘ 派生クラスでの実装を強制する
Protected MustOverride Sub ProcessCore()
End Class
Public Class ExcelToSqlProcessor : Inherits DataProcessor
‘ Overridesにより、基底クラスの契約を履行する
Protected Overrides Sub ProcessCore()
‘ ここにExcel読み込みとDB挿入の具体的なロジックを記述
‘ 呼び出し元は型を意識せずExecute()を呼ぶだけで良い
End Sub
End Class
避けられない場合のShadows活用
サードパーティ製のライブラリ（変更できない基底クラス）と、どうしても同名のメソッドが必要な場合のみ、例外的に`Shadows`を使用する。
Public Class LegacyWrapper
‘ 外部ライブラリのメソッドを隠蔽し、自前のログ出力機能を追加する
Public Shadows Sub SaveData(data As String)
Logger.Info(“データ保存開始”)
MyBase.SaveData(data) ‘ 基底クラスの機能をラップして安全に使う
Logger.Info(“データ保存完了”)
End Sub
End Class
—
4. 業務自動化エンジニアへの警告
最後に、ファイルやデータベース連携を自動化する諸君へ。
1. 「隠蔽」は禁じ手と思え： `Shadows`を使う際は、必ず「なぜこれが必要なのか」をコード内にコメントとして記述すること。理由なき`Shadows`は、将来の貴方の首を絞める。
2. 型に頼った実装を排除せよ： `DirectCast`や`CType`を多用しなければならないコードは、継承設計に欠陥がある証拠。`Overrides`を活用して、インターフェースまたは抽象クラスを通じた呼び出しに一本化せよ。
3. ライフサイクルを意識せよ： 継承階層が深くなると、`Dispose`の連鎖が壊れやすい。`Overrides`を使う際は、`MyBase.Dispose(disposing)`の呼び出し漏れがないか、常にチェックする癖をつけよ。
継承は強力な武器だが、制御できなければ爆発する。`Overrides`で拡張性を確保し、`Shadows`は防壁として慎重に扱う。このバランス感覚こそが、世界最高峰の自動化エンジニアへの第一歩である。
設計の指針は明確だ。あとは、貴方のエディタでそれを体現するだけだ。健闘を祈る。
