仮想メンバー
Note
このコンテンツは、Pearson Education, Inc. の許可を得て、『Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition (フレームワーク設計ガイドライン: 再利用可能な .NET ライブラリの規約、表現形式、およびパターン、第 2 版)』から転載されています。 この版は 2008 年に出版され、その後、この本は第 3 版で全面的に改訂されました。 このページの情報の一部は古くなっている可能性があります。
仮想メンバーはオーバーライドすることができ、それによってサブクラスの動作を変更することができます。 それらは、提供される機能拡張に関してコールバックとよく似ていますが、実行のパフォーマンスとメモリの消費に関してはそれよりも優れています。 また、仮想メンバーは、特別な種類の既存の型を作成 (特殊化) する必要があるシナリオでは、より自然に感じられます。
仮想メンバーのパフォーマンスは、コールバックとイベントよりも優れていますが、非仮想メソッドほどは優れていません。
仮想メンバーの主な欠点は、仮想メンバーの動作はコンパイル時にのみ変更できることです。 コールバックの動作は、実行時に変更できます。
仮想メンバーは、コールバックのように (おそらくコールバック以上に)、設計、テスト、およびメンテナンスにコストがかかります。これは、仮想メンバーへのすべての呼び出しは予測不可能な方法でオーバーライドされ、任意のコードが実行される可能性があるためです。 また、仮想メンバーのコントラクトを明確に定義するには、通常はさらに多くの労力が必要であるため、それらを設計して文書化するコストが高くなります。
❌ メンバーを仮想にする正当な理由があり、かつ仮想メンバーの設計、テスト、およびメンテナンスに関連するすべてのコストを把握している場合を除いて、メンバーを仮想にしないでください。
仮想メンバーは、互換性を損なわずに実行できる変更という観点から見ると、許容度が低くなっています。 また、ほとんどの場合、仮想メンバーへの呼び出しはインライン化されないため、非仮想メンバーよりも処理速度が遅くなります。
✔️ 絶対に必要な範囲にのみ、機能拡張を制限することを検討してください。
✔️ 仮想メンバーに対するアクセシビリティは、パブリックなものよりも保護されたものを優先してください。 パブリック メンバーは、保護された仮想メンバーを呼び出すことで (必要に応じて) 拡張性を提供する必要があります。
クラスのパブリック メンバーは、そのクラスを直接使用するものに対して、適切な機能セットを提供する必要があります。 仮想メンバーはサブクラスでオーバーライドされるように設計されており、保護されたアクセシビリティは、すべての仮想拡張ポイントのスコープを、それらが使用できる場所に設定するための優れた方法です。
Portions © 2005, 2009 Microsoft Corporation. All rights reserved.
2008 年 10 月 22 日に Microsoft Windows Development シリーズの一部として、Addison-Wesley Professional によって発行された、Krzysztof Cwalina および Brad Abrams による「Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition」 (フレームワーク デザイン ガイドライン: 再利用可能な .NET ライブラリの規則、用法、パターン、第 2 版) から Pearson Education, Inc. の許可を得て再印刷されています。