由于我怕文章的篇幅過長會使人看了頭痛，所以，我打算分幾篇文章把《.NET設計規范》第二章的學習筆記寫出來，這樣大家看著不至于太累！大概是接下去總共五篇文章是說“框架設計基礎”的......

對用戶而言，真正的開發效率來自能夠輕易地創造出非凡的產品，而并非來自能夠輕易地創造垃圾。

場景驅動設計的原則

框架通常包含非常大的一組API。但在開發過程中，真正用到的只是其中較小的一個子集，只會涉及一小部分常用場景。

在設計框架時，使用場景來驅動。從用戶的角度，先自己編寫一些對主要場景來說必不可少的代碼，然后再設計對象模型（object model）來支持這些樣例代碼。

于功能性規范之前，先撰寫一份場景驅動的API規范，應該列出一個給定的技術領域中最常用的5—10個使用場景，并列出實現這些場景的樣例代碼，至少用兩種語言編寫。

• 要確保對任何包含公用API的特性設計來說，其核心部分都是API設計規范。
• 要為每個主要的特性域（feature area）定義一些最常用的場景。
• 要確保使用場景與適當的抽象層次相對應。場景應該大致與最終用戶的用例相對應。
• 先為主要的使用場景編寫樣例代碼，然后再定義對象模型來支持這些樣例代碼。
• 要用至少兩種不同的編程語言來為主要場景編寫樣例代碼。
  最好能保證所選編程語言的語法和風格差異很大。
• 不要在設計框架的公用API時完全依賴于標準的設計方法。
  標準的設計方法（包括面向對象的方法）是為了使設計的具體實現容易維護，而不是為了使得到的API易于使用。
  以場景驅動設計為主，輔以原型制作、可用性研究以及一定數量的迭代，這種方法要比標準的設計方法好得多。
  可用性研究是為了確定開發人員真正的需求。這跟需求獲取一樣，設計師此時化身為一名需求分析師，而開發人員則變成了客戶。需求分析師不能想當然的認為客戶的真正需求是什么，一定要通過跟客戶交流才行，站在客戶的角度考慮問題。跟需求獲取類似，可用性研究宜早不宜遲。
• 要安排可用性研究來測試用于主要場景的API。
  如果開發人員在為主要場景編寫代碼時，遇到較大問題，則說明API需要重新設計。在原有API的基礎上修改，開銷反而大，而且是很大。

待續....