仮想メンバーVirtual Members

そのため、サブクラスの動作を変更する仮想メンバーをオーバーライドできます。Virtual members can be overridden, thus changing the behavior of the subclass. それらは、それらのもたらす拡張性の観点からのコールバックとよく似ていますが、実行のパフォーマンスとメモリ消費量の観点からは優れています。They are quite similar to callbacks in terms of the extensibility they provide, but they are better in terms of execution performance and memory consumption. また、仮想メンバー自然に感じられる特殊な既存の型 (特殊化) の種類を作成する必要のあるシナリオでします。Also, virtual members feel more natural in scenarios that require creating a special kind of an existing type (specialization).

仮想メンバーはコールバックとイベントをよりパフォーマンスが向上しますが、非仮想メソッドよりも優れた実行しません。Virtual members perform better than callbacks and events, but do not perform better than non-virtual methods.

仮想メンバーの主な欠点は、仮想メンバーの動作はコンパイル時にのみ変更できます。The main disadvantage of virtual members is that the behavior of a virtual member can only be modified at the time of compilation. 実行時に、コールバックの動作を変更できます。The behavior of a callback can be modified at runtime.

コールバック (およびそれよりコールバックの他の情報) などの仮想メンバーを設計、テスト、および仮想メンバーへの呼び出しが予期しない方法でオーバーライドでき、任意のコードを実行できるので、管理コストがかかります。Virtual members, like callbacks (and maybe more than callbacks), are costly to design, test, and maintain because any call to a virtual member can be overridden in unpredictable ways and can execute arbitrary code. また、さらに多くの労力は通常、設計と、それらを文書化のコストが高いため、仮想メンバーのコントラクトを明確に定義する必要です。Also, much more effort is usually required to clearly define the contract of virtual members, so the cost of designing and documenting them is higher.

X DO NOT これを行うには相応の理由があり、デザイン、テスト、および仮想メンバーを保守に関連するすべてのコストを認識している限り、メンバーを仮想にすることです。X DO NOT make members virtual unless you have a good reason to do so and you are aware of all the costs related to designing, testing, and maintaining virtual members.

仮想メンバーは、互換性の問題なしに作成できる変更の観点からありました。Virtual members are less forgiving in terms of changes that can be made to them without breaking compatibility. また、これらは、非仮想メンバーよりも低速仮想メンバーへの呼び出しがインラインでないため、ほとんどの場合です。Also, they are slower than non-virtual members, mostly because calls to virtual members are not inlined.

✓ CONSIDER に何がどうしても必要なだけの機能拡張を制限します。✓ CONSIDER limiting extensibility to only what is absolutely necessary.

✓ DO 仮想メンバーのアクセシビリティは public で保護されたアクセシビリティを優先します。✓ DO prefer protected accessibility over public accessibility for virtual members. パブリック メンバーが拡張機能を提供 (必要な) 場合プロテクト仮想メンバーを呼び出すことによって。Public members should provide extensibility (if required) by calling into a protected virtual member.

クラスのパブリック メンバーは、そのクラスの直接のコンシューマー向けの機能の適切なセットを提供する必要があります。The public members of a class should provide the right set of functionality for direct consumers of that class. 仮想メンバーは、サブクラスで上書きするように設計し、保護されたアクセシビリティが使用する場所のすべての仮想機能拡張ポイントをスコープする優れた方法です。Virtual members are designed to be overridden in subclasses, and protected accessibility is a great way to scope all virtual extensibility points to where they can be used.

Portions © 2005, 2009 Microsoft Corporation.All rights reserved.Portions © 2005, 2009 Microsoft Corporation. All rights reserved.

Pearson Education, Inc. からのアクセス許可によって了承を得て転載Framework デザイン ガイドライン。規則、手法、および再利用可能な .NET ライブラリの第 2 版のパターンKrzysztof Cwalina、Brad 内容では、Microsoft Windows の開発シリーズの一部として、Addison-wesley Professional、2008 年 10 月 22日を公開します。Reprinted by permission of Pearson Education, Inc. from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, published Oct 22, 2008 by Addison-Wesley Professional as part of the Microsoft Windows Development Series.

関連項目See also