《NET 設計規範》第 2 章 框架設計基礎

　　要設計功能強大又易於使用的框架。

　　要理解廣大開發人員並有針對性地為他們設計框架。

　　要理解各種編程語言，併為他們設計框架。　　

　　要確保在設計任何包含公用API的特性時，把 API 設計規格書作為它最核心的部分。

　　要為每個主要的特性域定義一些最常見的使用場景。

　　要確保使用場景與適當的抽象層次相對應。場景應該大致與最終用戶的用例相對應。

　　要在設計 API 時，先為主要的使用場景編寫樣例代碼，然後在定義對象模型來支持這些樣例代碼。

　　要用至少兩種不同風格的編程語言來為主要場景編寫樣例代碼。

　　考慮用動態類型語言來為主要場景編寫樣例代碼。

　　不要在設計框架的公用 API 時完全依賴於標準的設計方法。

　　要安排可用性測試研究來測試用於主要場景的 API。

　　要確保每個主要特性域的命名空間只包含那些用於最常見場景的類型。應該把用於更高級場景的類型放在子命名空間中。

　　要為構造函數和方法提供簡單的重載函數。一個簡單的重載函數不僅參數的數量非常少，而且所有的參數都是基本類型。

　　不要把用於高級場景的成員放在為主要使用場景而設計的類型中。

　　不要要求用於在最基本的場景中顯示地實例化一個以上的類型。

　　不要要求用戶在為基本使用場景編寫代碼之前就進行大量的初始化。

　　要儘可能地（用便利的重載函數）為所有的屬性和參數提供合適的預設值。

　　要通過異常來傳達對 API 的誤用。

　　要確保 API 是直觀的，無需查閱參考文檔就能用於基本場景。

　　要為所有的 API 提供優秀的文檔。

　　要在審查規格書的時候投入大量的時間和精力，來討論標識符名稱的選擇。

　　不要擔心標識符的名字太冗長。

　　考慮在設計過程的早期讓用於教育專家參與。考慮把最好的名字留給常用類型。

　　要通過異常消息來告訴開發人員對框架的誤用。

　　要儘可能地提供強類型的 API。

　　要確保與 .NET 框架以及客戶可能會使用的其它框架保持一致。

　　避免在主要場景的 API 中使用太多的抽象。

　　考慮對框架進行分層，使高層API能夠提供最佳的開發效率，低層API能提供最強大的功能和最豐富的表現力。

　　避免把非常複雜（即包含許多類型）的低層API和高層API混在同一個命名空間中。

　　要確保單個特性域中不同的層能很好地集成在一起。開發人員應該能在開始時使用其中一層來進行開發，然後通過修改代碼就可以使用另一層，而且這樣的改動應該無需重寫整個應用程式。

【原文】http://www.cnblogs.com/liqingwen/p/7147887.html