抽象 (抽象類型和介面)
注意
此內容是由 Pearson Education, Inc. 授權轉載自架構設計指導方針：可重複使用 .NET 程式庫的慣例、慣用語和模式，第 2 版。 該版於 2008 年出版，該書自那以後已於第三版進行了全面修訂。 此頁面上的某些資訊可能已過期。
抽象概念是指描述合約，但未提供合約完整實作的類型。 抽象概念通常實作為抽象類別或介面，而且隨附一組定義完善的參考文件，描述實作合約類型的必要語意。 .NET 架構中最重要的一些抽象概念包括 Stream、IEnumerable<T> 和 Object。
如果想要擴充架構，您可以實作支援抽象概念合約的具象類型，並使用這個具象類型搭配架構 API 以取用 (操作) 抽象概念。
經得起時間考驗、有意義且實用的抽象概念非常難設計， 主要困難在於取得恰到好處的成員集，不多也不少。 如果抽象概念的成員過多，則不容易或甚至不可能實作。 如果承諾功能的成員太少，則在許多有趣的案例中會變得無用。
架構中的抽象概念太多也會對架構的可用性造成負面影響。 如果不了解抽象概念如何融入具體實作以及在抽象概念上運作的 API，往往很難理解抽象概念。 此外，抽象概念及其成員的名稱都必須為抽象，如果不先了解其使用方式的相關內容，通常會難以理解且無法套用。
不過，抽象概念可提供非常強大的擴充性，遠超其他擴充性機制。 抽象概念是許多架構模式的核心，例如外掛程式、控制反轉 (IoC)、管線等等。 抽象概念對於架構的可測試性也至關重要。 良好的抽象概念可簡化複雜的相依性，以便進行單元測試。 總而言之，抽象概念能夠提供現代物件導向架構所追求的豐富性。
❌ 請勿提供未經測試的抽象概念，測試方法為開發數個具體實作以及透過 API 取用抽象概念。
✔️ 設計抽象概念時，請務必謹慎選擇抽象類別和介面。
✔️ 請考慮提供抽象概念具體實作的參考測試。 這類測試應該允許使用者測試其實作是否能正確實作合約。
Portions © 2005, 2009 Microsoft Corporation. 著作權所有，並保留一切權利。
獲 Pearson Education, Inc. 的授權再版，從 Krzysztof Cwalina 和 Brad Abrams 撰寫，並在 2008 年 10 月 22 日由 Addison-Wesley Professional 出版，作為 Microsoft Windows Development Series 一部份的 Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition 節錄。