本文重點

1. Framework設計的一大挑戰
2. Framework設計的基本原則

Challenge

老實說這篇看到一半覺得挺無力的

裡面講的好多東西都好難做到喔

難怪昨天說的Well-Designed Framework是昂貴的

昨天說到Well-Designed Framework要能考量各種狀況，語言，工具。包山包海

這篇就教你如何包山包海包大人

並不是全部的東西都要納進來，但要納進來的東西最好能考慮周全

本篇圍繞著一個主題

如何設計出一個成功的Framework

一個既強大又簡單的Framework

強大又簡單聽起來似乎很矛盾，似乎很難同時存在

沒有關係的，請遵守20/80原則

確定需求、工具、語言後，大致上可以鎖定開發範圍

針對20%重要的功能設計各種情境完整開發

其他80%的不重要的廢物功能請簡單開發

鎖定開發範圍，各種情境、工具跟需求

針對不同的程式語言做客製

Framework設計的基本原則

不要想說你要開發甚麼功能，怎樣設計內容如何

先想著甚麼情況下使用這個功能?

使用者如何使用這個功能?

然後根據情境需求開spec

以下介紹一個情境式開發的spec範本(本書附錄C)

目錄

1. Requirements
2. Api Specification
   2.1 Scenarios
   2.1.1 Measure Time Elapsed
   2.1.2 Measure Time Elapsed (Simplified)
   2.1.3 Resue Stopwatch (VB)
   2.1.4 Mesure Cumulative Intervals
   2.2 API Design
3. Functional Specification

1. 先搞懂需求
2. 確定有多少主要流程 (2.1.1 ~ 2.1.4)
   針對主要的情境寫來，並且將相關的情境做縮合，不要太繁瑣
   舉例而言，『讀取檔案內容』就是一個好的情境
   但是不要把裡面的『開檔』、『讀取內文』、『關檔』也列在目錄上
   這樣太繁瑣了
3. 先寫主程式，不要先寫方法。
   根據流程寫完主程式後，幾乎可以確定需要時做哪些方法

   Measure Time Elapsed
   Stopwatch watch = new Stopwatch();
   watch.Start();
   Thread.Sleep(1000);
   Console.WriteLine(watch.Elapsed);

4. 整理所有步驟3的方法，設計API
5. 把步驟4的程式整理成Functional Specification

太懶得打了，看圖吧。

同時工商服務一下，30天後需要二手書者請內洽喔

上面是步驟4的部份，設計AIP

下面則是整理Functional Specification的表格

明確定義每個Method的行為跟Exception

主要的程式至少要用兩種語言開發(eg, C# , C++)

已確保可以在不同的平台下執行

其實這有點歷史淵源了，現在新的.NET Code已經可以跨平台了

可以的話，再加上一種dynamically typed languaged，例如Python or Ruby

使用門檻低

市面上的Framework百百種，只要使用者覺得不好用

還有其他類似的Framework等著挑

Common的namespace是放所有人都可以用的工具，避免客製跟呼叫其他服務

Common的namespace不要超過500個Types，不要放些沒用的東西在裡面

在可能發生錯誤的地方throws Exception的方式讓使用者可以處理錯誤

多多使用Overload

本身就是文件

Object Models本身的可讀性要高

讓人一看就知道這是在做啥，減少使用者翻文件的頻率

讓程式本身就是文件

但是還是要針對所有的APIs提供全面性的文件

畢竟並不是所有程式都能簡單地達到這個目的

有下列幾種方法可以增加程式的可讀性

1. 統一的命名規則
2. 善用Exception來表示可能發生的狀況
3. 別太抽象化

使用分層架構

善用Namespace做分層

在.NET裡叫Namespace，在Java中教Package

在檔案總管理就是一個資料夾

Namespace就像抽屜一樣，把相關的東西放在一起

然後再同一個抽屜（Namespace）中又可以使用夾層（還是Namespace)做進一步的分類

一個資料夾包資料夾紙包機包紙包雞的概念

最後附上我精美的筆記內容吧