クラスのシールによる機能拡張の制限
更新 : 2007 年 11 月
シールを使用すると、開発者がフレームワークを拡張する方法を制限できます。クラスをシールすると、そのクラスを他のクラスが継承できなくなります。また、メンバをシールすると、派生クラスがそのメンバの実装をオーバーライドできなくなります。既定では、型とメンバはシールしません。シールすると、ライブラリの型とメンバをカスタマイズできなくなり、使い勝手が悪くなったと感じる開発者が現れる可能性もあります。また、機能拡張は、オブジェクト指向フレームワークを使用する基本的な利点の 1 つです。この利点を制限する決定は、慎重に検討したうえで行う必要があります。
十分な根拠がない場合はクラスをシールしないでください。
クラスの拡張が必要なシナリオが認められないという理由で、クラスをシールするのが適切であるとは思わないでください。次のような特定の条件を満たすクラスはシールする必要があります。
クラスが静的である。
クラスに、セキュリティ関連情報を持つ、継承されたプロテクト メンバが含まれる。
クラスが多くの仮想メンバを継承しており、クラス全体をシールする場合に比べ各メンバをシールした場合の開発およびテスト コストが著しく高くなる。
クラスが、リフレクションを使用した迅速な検索を必要とする属性である。属性をシールすると、属性の取得時にリフレクションのパフォーマンスが向上します。
シールされた型でプロテクト メンバや仮想メンバを宣言しないでください。
型がシールされている場合は、派生クラスを持つことができません。プロテクト メンバは派生クラスからしかアクセスできず、仮想メンバは、派生クラスでしかオーバーライドできません。
オーバーライドするメンバはシールすることを検討してください。
この方法を使用すると、現在のクラスとすべての派生クラスに必要な動作を派生クラスが変更または省略できなくなります。
Portions Copyright 2005 Microsoft Corporation.All rights reserved.
Portions Copyright Addison-Wesley Corporation.All rights reserved.
デザイン ガイドラインの詳細については、2005 年に Addison-Wesley から出版されている Krzysztof Cwalina、Brad Abrams 共著の『Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries』を参照してください。