次の方法で共有


シールされていないクラス

Note

このコンテンツは、Pearson Education, Inc. の許可を得て、『Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition (フレームワーク設計ガイドライン: 再利用可能な .NET ライブラリの規約、表現形式、およびパターン、第 2 版)』から転載されています。 この版は 2008 年に出版され、その後、この本は第 3 版で全面的に改訂されました。 このページの情報の一部は以前のものである可能性があります。

シールされたクラスから継承することはできません。これらは拡張できないようになっています。 対照的に、継承が可能なクラスは、シールされていないクラスと呼ばれます。

✔️ コストをかけずにフレームワークに高い拡張性を提供する優れた方法として、シールされていないクラスを、仮想または保護されたメンバーを追加せずに使用することを検討してください。

開発者は、シールされていないクラスから継承を行って、カスタム コンストラクターや新しいメソッド、メソッド オーバーロードなどの便利なメンバーを追加したいと思うことがよくあります。 たとえば、System.Messaging.MessageQueue はシールされていないため、ユーザーは特定のキューのパスを既定とするカスタム キューを作成したり、特定のシナリオで API を簡略化するカスタム メソッドを追加したりできます。

ほとんどのプログラミング言語では、クラスは既定でシールされていません。これは、フレームワークのほとんどのクラスに対する既定の設定としても推奨されます。 シールされていない型によって実現される拡張性は、フレームワーク ユーザーに高く評価されており、シールされていない型に関連するテスト コストが相対的に低いため、コストをかけずに提供されます。

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. の許可を得て再印刷されています。

関連項目