【VB.NET極意】ShadowsとOverridesの境界線：継承の闇を制御し、バグを葬り去る設計術
業務自動化の現場で「継承」を使いこなせていると自負している諸君。だが、`Shadows`と`Overrides`を「なんとなく動くから」という理由で使い分けてはいないか？
この二つのキーワードは、単なる構文の差異ではない。「君が設計したオブジェクトが、予測可能な挙動をするか、それとも将来のバグの温床となるか」を分かつ境界線だ。
今回は、業務システム開発の現場で避けては通れない、この継承の深淵について、アーキテクトの視点から紐解いていこう。
—
1. 概念の核心：なぜ二つの道が存在するのか
まずは結論から言おう。
- `Overrides`: 基底クラスの振る舞いを「正当に進化」させる。多態性（ポリモーフィズム）の恩恵を最大限に受けるための道。
- `Shadows`: 基底クラスのメンバを「無力化・隠蔽」する。継承関係を断ち切り、新たな実装を強引に割り込ませるための禁じ手。
なぜ「Shadows」が存在するのか？
「継承したのにメソッドを隠すなら、最初から継承するな」という正論は正しい。しかし、外部ライブラリのクラスを継承せざるを得ない場合や、型定義を意図的に上書きして特定インターフェースとの整合性を保ちたい場合など、現実は綺麗事では済まない。
`Shadows`は、「基底クラスの設計を修正できない状況下での、最後の緊急回避策」であると心得よ。
—
2. 破壊的バグを生まないための比較表
| 比較項目 | Overrides (上書き) | Shadows (隠蔽) |
| :— | :— | :— |
| 多態性 | 維持される（基底型で扱っても派生側のメソッドが呼ばれる） | 断絶される（基底型で扱うと基底側のメソッドが呼ばれる） |
| 設計思想 | 拡張・機能強化 | 置き換え・無視 |
| 推奨度 | 高 (オブジェクト指向の王道) | 低 (局所的な特例のみ) |
—
3. 実践：プロダクションコードでの使い分け
業務自動化ツールでよくある「CSV出力ロジック」を例に、堅牢な設計を見てみよう。
ケースA：Overridesを使うべき（正当な拡張）
基底クラスの`Export`メソッドを、派生クラスで「ログ出力機能を付加」して拡張するケース。
.net
Public Class BaseExporter
‘ Overridableを明示することで、継承を許可する意思を伝える
Public Overridable Sub Export(data As String)
Console.WriteLine(“ファイルに書き込み中: ” & data)
End Sub
End Class
Public Class CsvExporter
Inherits BaseExporter
‘ 基底の挙動を活かしつつ、追加処理を実装
Public Overrides Sub Export(data As String)
Console.WriteLine(“ログ出力開始…”)
MyBase.Export(data) ‘ 基底のメソッドを確実に呼び出す
Console.WriteLine(“ログ出力終了。”)
End Sub
End Class
ケースB：Shadowsを使うべき（意図的な隠蔽）
外部ライブラリの仕様で、意図せず定義されたメソッドを完全に「封印」したい場合。
.net
Public Class ExternalLegacySystem
Public Sub Process()
‘ 危険な処理が含まれていると仮定
Throw New Exception(“この処理は直接実行してはならない！”)
End Sub
End Class
Public Class SecureSystem
Inherits ExternalLegacySystem
‘ 継承はされているが、このメソッドは無効化する
Public Shadows Sub Process()
‘ 何もしない、もしくは安全な独自処理に差し替える
Console.WriteLine(“安全な処理に差し替えられました。”)
End Sub
End Class
—
4. アーキテクトからの警告：バグを避ける鉄則
現場でよく見る「動かない」「挙動が謎」という相談のほとんどは、「ShadowsとOverridesの混同」に起因する。以下の鉄則をコードレビューの基準にせよ。
1. 「型」の意識を忘れるな
`Shadows`を使った場合、変数を`BaseClass`型として宣言すると、`Shadows`したはずのメソッドが呼ばれてしまう。これが「基底型で扱った時だけ挙動が変わる」という悪魔的なバグの正体だ。
2. `MyBase`の安易な利用を避ける
`Overrides`した際には`MyBase`を使うのがセオリーだが、`Shadows`において`MyBase`を使うことは、意図的に隠したはずの機能を引きずり出すことであり、構造を複雑にする。
3. 継承よりもコンポジション（合成）を検討せよ
「継承したくないメンバが多い」「基底クラスの仕様が不安定」と感じるなら、それは継承のタイミングではない。クラスを委譲（Delegation）で構成し直す勇気を持て。
—
5. 最後に：エンジニアとしての矜持
`Overrides`は「継承という契約」を尊重する紳士的な設計だ。
一方、`Shadows`は「状況を強引にねじ伏せる」ための荒療治である。
業務自動化ツールは、一度組めば長く使い続けられるものだ。だからこそ、今書いているそのコードが「数年後の自分が読んでも意図が明確か」を常に自問自答してほしい。
「なぜShadowsを使ったのか？」
この問いに対し、明確な論理的回答を持てるエンジニアだけが、メンテナンスコストを最小化し、ビジネスの成長を加速させる真の自動化エンジニアと言える。
さあ、コードを開け。君の設計は「継承の秩序」を守っているか？
