框架是：

• 應用或子系統的設計
• 表示為：
• 一組抽象類和
• 這些類中對象的協作方法

用框架來創建應用通過:

• 建立一個新的子類
• 組合對象
• 修改運行中的程序

(編輯腳本)

逆向控制

子程序庫

用戶程序調用可重用的代碼.

用戶設計程序結構.

框架

重用代碼調用客戶程序

主要由重用代碼(框架)決定程序結構

框架應用的部件

新的類使用組件的步組L

• 建立組件
• 連接組件
• 參數化組件

測試框架

類 - Test, TestResult, TestSuite

通過創建 Test的子類來使用。

定義 instance methods 來 配置、運行測試

定義 class methods 來建立一個測試單元

Model/View/Controller

Classes - Model, View, Controller, ApplicationModel, ValueModel, etc.

Use by using GUI builder to make a screen; the GUI builder automatically builds an ApplicationModel and a window-spec that later gets interpreted to build a window.

HotDraw

Classes - Figure, Drawing, Handle, Tool, DrawingEditor

Subclass DrawingEditor, Figure, rarely Drawing

Parameterize Handle, Tool.

There is a graphical tool for defining new Tools.

White-box vs. Black-box

White-box

用戶化通過定義子類強調繼承

必須了解內部結構

設計簡單容易

學習困難，需要更多的編程

Black-box

通過配置用戶化

強調多態

必須了解接口

設計復雜、困難

學習容易，需要較少的編程

框架設計的第一規則

相關的原則

框架是抽象: 人們從實際的應用中歸納出來

設計重用的代碼需要疊代

框架編碼領域知識

框架的客戶是程序員（譯者：最終還是應用的客戶）

從實際案例中歸納

人們思考是具體的，不是抽象的.

通過研究具體的例子抽象被徹底的發現

歸納:

• 找出名稱不同的相同事物,
• 通過參數化排除差異,
• 把大的事物分解成小的部分以發現類似的組件, 并且
• 分類相似的事物.

發現抽象類

抽象類的發現是通過歸納具體類.

定義類共有的SuperClass:

• 定義操作的公共接口
• 把具有相同實現的操作轉移到SuperClass
• 把實現不同的操作定義為抽象操作
  (continued)
• 定義公共接口（interface）
  • 重命名操作使各個類有相同的操作名
  • 重新排列參數、修改參數類型等.
  • 重構 操作

框架需要迭代

能夠重用的代碼需要多次迭代.

軟件工程基本規則

如果程序沒有測試, 他將不能工作.

結論: 還沒被重用的軟件是不能重用的.

框架編碼領域知識

框架解決特定的一組問題.

Not always application-domain specific, but domain specific. (GUI, distribution, structured drawing editor, business transaction processing, workflow)

客戶是程序員

框架的目的是更容易的構建應用.

適用這些標語為程序員:

客戶總是正確的.

我們是客戶驅動.

理解你的客戶.

實例驅動的設計

歸納是迭帶的.

小的改變是最多的.

少數大的改變代表看待問題的新方法.

更快的歸納:

• 接受不同的意見
• 解釋/辯護 當前的設計

開發框架的理想的方法

1) 分析問題域

• 學習眾所周知的抽象.
• 收集用框架編寫的例子程序. (最少 4 or 5).

設計框架的理想方法

2) 設計覆蓋例子的抽象.

3) 通過編寫這些例子來測試框架.

• 每個例子都是相互獨立的程序.
• 履行一個測試意味著開發一個軟件.

抽象設計

設計階段: 尋找共性, 描述每個想法.

用設計模式

• 暗示需要經驗

靈活性和洞察力是有用的, 而且進展是困難的.

設計模式

設計模式使設計更接近黑盒.

怎樣表示對象的變化

• Strategy -- 算法
• Prototype -- 產品
• State -- 對象的狀態
• Mediator – 對象相互調用的方法

設計模式的使用

模式使設計更復雜.

模式使設計更有彈性.

你需要這種彈性嗎?

這復雜性是否值得?

在兩個模式中做選擇時選擇使設計更簡單的.

為什么理想永遠是理想

分析領域需求分析個別的例子,已經是非常困難的.

• 即使例子已經被分析也僅僅實用.
• 分析和實現例子是工程的很大一部分成本.
• 人們需要匯集例子實現的反饋.

開發框架的好辦法

精選兩個相似的應用.

包括在相同領域有經驗的開發者.

一個框架組

兩個應用組

• 框架組
  交換軟件意見
  考慮其他的應用
  解釋教受框架
• 應用組
  盡力重用框架
  抱怨框架如何難于使用

開發框架的典型方法

注意到許多應用是相似的.

用面向對象的語言開發領域中的下一個應用.

把軟件劃分為可重用和不可重用兩部分.

開發下一個應用盡可能的重用可重用的部分.

驚奇! 框架的重用性不好.

修改.

開發下一個盡可能重用的軟件.

重用的副作用

相互沖突的目標

• 按時交付系統
• 重用

重用的花費是昂貴的

堅持重用是困難的

重用的有利的一面

框架使用者利用框架開發者的經驗.

僅增加有價值的特性.

幫助防止框架太復雜、太抽象.

另一種策略

定義框架 – 原形幾個小的應用.

創建真實應用.

重構框架和老的應用.

過程摘要

以想得到的應用的例子開始

疊代的開發抽象

通過創建應用來測試

細節

1) 三個例子

2) White-box 框架

3) 組件庫

4)熱點（ Hot Spots）

5) 扁平化對象

(continued)

6) 平滑對象

7) Black-box 框架

8) Visual Builder

9) 語言工具

http://st-www.cs.uiuc.edu/users/droberts/evolve.html

應用產生器

Black-box 更容易:

用a picture描述應用

從 a picture產生代碼

可視化編程語言使非程序員也能創建應用.

黑盒框架的缺點

黑盒框架趨向于有：

• 更多種類的對象
• more artificial kinds of objects（真不知怎么描述？）
• 對象間更復雜的關系
• 更多對象

不完善的框架強迫你調試更復雜的系統.

模版和重構

重構

• 在不影響功能的情況下改變程序結構.
• 修改重用問題的方法.
• 創建一個彈性的 "hot spot"
• 經常應用一個模版

重構幫助發現組合

框架設計提示

用對象組合代替繼承

多使用模版 /少泛化

框架應該打破限制

戰略

開發框架是昂貴的,想清楚再做.

• 框架開發需要長的周期.
• 好的框架能給你帶來競爭優勢.

從簡單開始.

• 有 OOP經驗
• 選擇訓練好的抽象
• 先建一個小的框架
• 歸納已經存在的系統
• 起先保持小的用戶群

客戶是至關緊要的

進早的找到用戶,并聽取他們的反饋.

是你最初的客戶成功.

最初的客戶是開發小組的一部分.

重用的環節

現實: Projects may customize the initial framework, and start competing streams of development.

處理疊代

不要說框架是有用的除非你的客戶這么說.

當框架演化時保持小的客戶群.

一個成功的框架必須不斷發展來適應新的用戶需求.

不要不停的修補. 有計劃的發布版本 并協調客戶.

文檔和練習

框架文檔的價值在

• 怎樣使用
• 怎么擴展 /他如何工作

重用的程序一定要是可理解的.

精練的文檔使框架更重用.

文檔以例子為基礎.

文檔和練習必須經過測試.

Documenting system shows how to change it.

Framework developers must be intimately involved.

NIH vs. TILI

Problem with reuse is NOT fault of customer.

Software is not as reusable as it is claimed.

It is hard to make software reusable.

可重用的設計是困難的

• 對于應用領域 框架必須是抽象并強大的
• 必須是可定制的對于用戶
• 必須容易理解
  • 簡單是至關重要的
  • 需要好的文檔