Framework Design Guidelines 筆記 (3) : 情節驅動設計

這是 Framework Design Guidelines 2nd edition 筆記的第 3 篇，基本介紹和表示法請參閱第 1 篇和第 2 篇。
關鍵詞彙

• scenario-driven design（情節驅動設計）
• use cases（使用案例）
• test-driven development, TDD（測試驅動開發）

以下開始內容摘要，我自己的話用暗橘色標示。
==========================================
情節驅動設計的原則

我們建議框架設計師先就框架使用者（按：我們常說的 app programmers）所欲處理的主要情節來撰寫程式碼，之後再根據這些範例程式碼來設計合適的物件模型。

此做法有點類似 TDD 或使用案例驅動的設計方式，但 TDD 算是比較重量級的方法，因為它除了驅動 APIs 的設計之外，還有一些別的目標；使用案例則是從較高的層次來描述情節，而不是從個別 API 呼叫的角度來思考。（scenario、use case、requirement、function，這幾個名詞也許是因為涵義相近或有重疊之處，翻譯成中文時常見有混用的情況，例如把 scenario 稱作「需求」，把 use case 稱作「功能」等等，如此固然「平易近人」，在某些場合卻可能過於含糊籠統。作者在書中對 scenario 和 use case 有比較明確的界定，閱讀時不妨留意一下。）

框架設計原則

設計框架的第一步，必須先從一組使用情節，以及實作這些情節的範例程式碼開始。

Krzysztof Cwalina：對此原則，我有句話要補充：「想要設計一個好框架，除此之外沒別的辦法。」如果這本書只能介紹一個設計原則，我一定會選這個。

框架設計師經常犯的錯誤，是先以各種設計方法論來設計物件模型，然後為這些設計好的 API 撰寫範例程式。問題是，大多數的設計方法（包括物件導向設計）都是以可維護性為主要考量，而未著重在 API 的易用性；它們非常適合用來設計僅供內部使用的程式架構，但不適合用來設計大型框架的共用 API 層。

• DO　先為主要情節撰寫範例程式碼，然後再從這些範例程式發展出對應的物件模型。

舉例來說，假設要設計一個 API 來計算某段程式的執行時間，你會先寫出類似下面的情節程式範例（有點像虛擬碼，注意裡面同時有 C# 與 VB 語法）：

// scenario #1: 計算執行時間
Stopwatch watch = Stopwatch.StartNew();
DoSomething();
Console.WriteLine(watch.Elapsed);

// scenario #2: 重複使用 stopwatch
Dim watch As Stopwatch = Stopwatch.StartNew()
DoSomething();
Console.WriteLine(watch.ElapsedMilliseconds)

watch.Reset()
watch.Start()
DoSomething()
Console.WriteLine(watch.Elapsed)

然後，根據這些程式碼發展出以下物件模型：

public class StopWatch
{
public static StopWatch StartNew();

public void Start();
public void Reset();

public TimeSpan Elapsed { get; }
public long ElapsedMilliseconds { get; }
...
}

也就是說，情節驅動設計就是從 API 使用者的角度出發，先想想看會怎麼用這些 API，並寫下範例程式碼。這些範例程式碼等於是 API 物件模型的需求規格，而接下來的工作就是根據這些範例程式碼來設計符合該需求的物件模型（類別）。

這種設計方式，也可以說是由上而下，從外（外部需求）到內（內部實作）吧！

相關文章

• 上一篇：Framework Design Guidelines 筆記 (2) : 漸進式框架
• 下一篇：Framework Design Guidelines 筆記 (4) : 低門檻原則