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