注
このコンテンツは、 フレームワーク設計ガイドライン (再利用可能な .NET ライブラリの規則、イディオム、パターン、第 2 版) から、Pearson Education, Inc. のアクセス許可によって再印刷されます。 そのエディションは2008年に出版され、その後 、本は第3版で完全に改訂されています。 このページの情報の一部が古くなっている可能性があります。
抽象化はコントラクトを記述するが、コントラクトの完全な実装を提供しない型です。 抽象化は通常、抽象クラスまたはインターフェイスとして実装され、コントラクトを実装する型の必要なセマンティクスを説明する明確に定義された一連の参照ドキュメントが付属しています。 .NET Framework の最も重要な抽象化には、 Stream、 IEnumerable<T>、 Objectなどがあります。
抽象化のコントラクトをサポートする具象型を実装し、抽象化を使用する (操作する) フレームワーク API でこの具象型を使用することで、フレームワークを拡張できます。
時間のテストに耐えることができる意味のある便利な抽象化は、設計が非常に困難です。 最も難しいのは、多すぎも少なすぎもしない適切なメンバーのセットを作成することです。 抽象化に含まれるメンバーが多すぎると、実装が困難または不可能になります。 約束された機能のメンバーが少なすぎると、多くの興味深いシナリオでは役に立たなくなります。
フレームワーク内の抽象化が多すぎると、フレームワークの使いやすさにも悪影響を及ぼします。 多くの場合、抽象化を理解するのは、具象実装の全体像と抽象化で動作する API にどのように適合するかを理解しないと、非常に困難です。 また、抽象化の名前とそのメンバーは必然的に抽象的であり、使用のより広範なコンテキストを最初に理解しない限り、おそらくそれらを不可解で近づきづらいものにします。
ただし、抽象化によって非常に強力な拡張性が提供され、他の機能拡張メカニズムは一致しないことがよくあります。 これらは、プラグイン、制御の反転 (IoC)、パイプラインなど、多くのアーキテクチャ パターンの中核をなしています。 また、フレームワークのテスト容易性にも非常に重要です。 優れた抽象化により、単体テストの目的で重い依存関係をスタブ化できます。 要約すると、抽象化は、最新のオブジェクト指向フレームワークの求められている豊富さを担当します。
❌ 抽象化を使用するいくつかの具体的な実装と API を開発してテストしない限り、抽象化を提供しないでください。
✔️ 抽象化を設計するときは、抽象クラスとインターフェイスのどちらかを慎重に選択してください。
✔️ 抽象化の具体的な実装に関する参照テストを提供することを検討してください。 このようなテストでは、ユーザーが実装でコントラクトが正しく実装されているかどうかをテストできるようにする必要があります。
Portions © 2005, 2009 Microsoft Corporation. 無断転載を禁じます。
フレームワーク設計ガイドライン:再利用可能な .NET ライブラリの規則、イディオム、パターン、Krzysztof Cwalina および Brad Abrams による第 2 版は、2008 年 10 月 22 日に Microsoft Windows 開発シリーズの一部として Addison-Wesley Professional によって公開されました。