在簡單的使用場景中，一定要讓框架無需文檔就能使用。
- 要確保API是直觀的，無需查閱參考文檔就能用于基本場景
你總不希望寫個“Hello World”都去查閱API文檔吧。
- 要為所有的API提供優(yōu)秀的文檔。
一方面，并非所有的API都能自說明。不同的人會認為不同的API是自說明的；
另一方面，有些人想在開始使用API之前完全理解它們。
設計自說明API時最重要的一些考慮因素：
- 命名
要在規(guī)范檢查中重視標識符名稱的選擇；
不要擔心標識符的名字太冗長；
一眼就能看出相應的方法是做什么的，類型和參數(shù)是表示什么意思。
而且類型的名字如果足夠好，那么用到這些類型的代碼會更易于立即和維護。
要在設計過程的初期就讓用戶教育專家參與；
考慮把最好的名字留給最常用的類型。
- 異常
要通過異常消息來清楚地告訴開發(fā)人員對框架的誤用。
- 強類型
很明顯，調(diào)用Customer.Name要比調(diào)用Customer.Properties["Name"]容易。
要盡可能提供強類型API。
如果必須使用屬性包，那么應該為包中最常用的屬性提供相應的強類型屬性。
- 一致性
要確保與.NET框架以及客戶可能會使用的其他框架保持一致。
- 限制抽象的數(shù)量
標準面向對象設計方法會產(chǎn)生大量抽象。其目的是使代碼易于維護。然而如果框架中存在太多的抽象，則會要求用戶對框架的架構有深入的了解，不易于用戶使用。
避免在主要場景的API中使用太多的抽象。