備註
此內容經Pearson Education, Inc.授權從架構設計指導方針：可重複使用 .NET 程式庫的慣例、習慣用語與範式 (第2版)轉載。 該版於2008年出版，該書自那以後已於 第三版全面修訂。 此頁面的某些資訊可能已過期。
抽象概念是描述合約但未提供合約完整實作的類型。 抽象概念通常實作為抽象類或介面，而且它們隨附一組定義完善的參考檔，描述實作合約之型別的必要語意。 .NET Framework 中最重要的抽象概念包括 Stream、 IEnumerable<T>和 Object。
您可以透過實作符合抽象合約的具體型別，並使用此具體型別在架構 API 上運作（操作）抽象概念，來擴充框架。
能夠承受時間測試的有意義且有用的抽象概念很難設計。 主要困難是找到正確的成員數量，不多也不少。 如果抽象概念有太多成員，則很難或甚至不可能實作。 如果成員對於所承諾的功能而言太少，那麼在許多有趣的情境中，它會變得無用。
架構中的抽象概念太多也會對架構的可用性造成負面影響。 在不了解抽象概念的具體實作和操作其上的 API 以及這些如何融入更大圖景的情況下，通常很難理解抽象概念。 此外，抽象的名稱及其成員本來就很抽象，這通常使它們顯得神秘且難以理解，若不了解其使用的更廣泛背景。
不過，抽象概念提供非常強大的擴充性，而其他擴充性機制通常無法比對。 它們是許多架構模式的核心，例如外掛程式、控制反轉 （IoC）、管線等等。 它們對於架構的可測試性也非常重要。 良好的抽象使您能夠在單元測試中替代繁重的相依性。 總而言之，抽象概念是促成現代面向物件架構豐富性的重要因素。
❌ 請勿提供抽象概念，除非它們是透過開發數個具體實作和取用抽象概念的 API 進行測試。
✔️ 在設計抽象時，請在抽象類別和介面之間謹慎選擇。
✔️ 請考慮為抽象概念的具體實作提供參考測試。 這類測試應該允許用戶驗證其實現是否正確地執行程式合約。
© 2005年、2009年Microsoft公司部分。 保留所有權利。
經 Pearson Education, Inc. 許可重新刊登自 Krzysztof Cwalina 和 Brad Abrams 所著的 架構設計指導方針: 可重複使用的 .NET 程式庫慣例、慣用語和模式，第 2 版，2008 年 10 月 22 日由 Addison-Wesley Professional 發行，作為 Microsoft Windows 開發系列的一部分。