面向對象的范式是思考程序設計時一種新的
而且全然不同的方式
許多人最開始都會在如何構造一個項目上皺起了眉頭
事實上
我們可以作出一個
好
的設計
它能充分利用OOP提供的所有優點
有關OOP分析與設計的書籍大多數都不盡如人意
其中的大多數書都充斥著莫名其妙的話語
笨拙的筆調以及許多聽起來似乎很重要的聲明（見注釋）
我認為這種書最好壓縮到一章左右的空間
至多寫成一本非常薄的書
具有諷剌意味的是
那些特別專注於復雜事物管理的人往往在寫一些淺顯
明白的書上面大費周章！如果不能說得簡單和直接
一定沒多少人喜歡看這方面的內容
畢竟
OOP的全部宗旨就是讓軟件開發的過程變得更加容易
盡管這可能影響了那些喜歡解決復雜問題的人的生計
但為什麼不從一開始就把事情弄得簡單些呢？因此
希望我能從開始就為大家打下一個良好的基礎
盡可能用幾個段落來說清楚分析與設計的問題
[注釋]
最好的入門書仍然是Grady Booch的《Object
Oriented Design withApplications
第
版本》
Wiely & Sons於
年出版
這本書講得很有深度
而且通俗易懂
盡管他的記號方法對大多數設計來說都顯得不必要地復雜
不要迷失 在整個開發過程中
最重要的事情就是
不要將自己迷失！但事實上這種事情很容易發生
大多數方法都設計用來解決最大范圍內的問題
當然
也存在一些特別困難的項目
需要作者付出更為艱辛的努力
或者付出更大的代價
但是
大多數項目都是比較
常規
的
所以一般都能作出成功的分析與設計
而且只需用到推薦的一小部分方法
但無論多麼有限
某些形式的處理總是有益的
這可使整個項目的開發更加容易
總比直接了當開始編碼好！
也就是說
假如你正在考察一種特殊的方法
其中包含了大量細節
並推薦了許多步驟和文檔
那麼仍然很難正確判斷自己該在何時停止
時刻提醒自己注意以下幾個問題
(
) 對象是什麼？（怎樣將自己的項目分割成一系列單獨的組件？）
(
) 它們的接口是什麼？（需要將什麼消息發給每一個對象？）
在確定了對象和它們的接口後
便可著手編寫一個程序
出於對多方面原因的考慮
可能還需要比這更多的說明及文檔
但要求掌握的資料絕對不能比這還少
整個過程可劃分為四個階段
階段
剛剛開始采用某些形式的結構
階段擬出一個計劃 第一步是決定在後面的過程中采取哪些步驟
這聽起來似乎很簡單（事實上
我們這兒說的一切都似乎很簡單）
但很常見的一種情況是
有些人甚至沒有進入階段
便忙忙慌慌地開始編寫代碼
如果你的計劃本來就是
直接開始開始編碼
那樣做當然也無可非議（若對自己要解決的問題已有很透徹的理解
便可考慮那樣做）
但最低程度也應同意自己該有個計劃
在這個階段
可能要決定一些必要的附加處理結構
但非常不幸
有些程序員寫程序時喜歡隨心所欲
他們認為
該完成的時候自然會完成
這樣做剛開始可能不會有什麼問題
但我覺得假如能在整個過程中設置幾個標志
或者
路標
將更有益於你集中注意力
這恐怕比單純地為了
完成工作
而工作好得多
至少
在達到了一個又一個的目標
經過了一個接一個的路標以後
可對自己的進度有清晰的把握
干勁也會相應地提高
不會產生
路遙漫漫無期
的感覺
座我剛開始學習故事結構起（我想有一天能寫本小說出來）
就一直堅持這種做法
感覺就象簡單地讓文字
流
到紙上
在我寫與計算機有關的東西時
發現結構要比小說簡單得多
所以不需要考慮太多這方面的問題
但我仍然制訂了整個寫作的結構
使自己對要寫什麼做到心中有數
因此
即使你的計劃就是直接開始寫程序
仍然需要經歷以下的階段
同時向自己提出一些特定的問題
階段要制作什麼？ 在上一代程序設計中（即
過程化或程序化設計
）
這個階段稱為
建立需求分析和系統規格
當然
那些操作今天已經不再需要了
或者至少改換了形式
大量令人頭痛的文檔資料已成為歷史
但當時的初衷是好的
需求分析的意思是
建立一系列規則
根據它判斷任務什麼時候完成
以及客戶怎樣才能滿意
系統規格則表示
這裡是一些具體的說明
讓你知道程序需要做什麼（而不是怎樣做）才能滿足要求
需求分析實際就是你和客戶之間的一份合約（即使客戶就在本公司內部工作
或者是其他對象及系統）
系統規格是對所面臨問題的最高級別的一種揭示
我們依據它判斷任務是否完成
以及需要花多長的時間
由於這些都需要取得參與者的一致同意
所以我建議盡可能地簡化它們——最好采用列表和基本圖表的形式——以節省時間
可能還會面臨另一些限制
需要把它們擴充成為更大的文檔
我們特別要注意將重點放在這一階段的核心問題上
不要糾纏於細枝末節
這個核心問題就是
決定采用什麼系統
對這個問題
最有價值的工具就是一個名為
使用條件
的集合
對那些采用
假如……
系統該怎樣做？
形式的問題
這便是最有說服力的回答
例如
假如客戶需要提取一張現金支票
但當時又沒有這麼多的現金儲備
那麼自動取款機該怎樣反應？
對這個問題
使用條件
可以指示自動取款機在那種
條件
下的正確操作
應盡可能總結出自己系統的一套完整的
使用條件
或者
應用場合
一旦完成這個工作
就相當於摸清了想讓系統完成的核心任務
由於將重點放在
使用條件
上
一個很好的效果就是它們總能讓你放精力放在最關鍵的東西上
並防止自己分心於對完成任務關系不大的其他事情上面
也就是說
只要掌握了一套完整的
使用條件
就可以對自己的系統作出清晰的描述
並轉移到下一個階段
在這一階段
也有可能無法完全掌握系統日後的各種應用場合
但這也沒有關系
只要肯花時間
所有問題都會自然而然暴露出來
不要過份在意系統規格的
完美
否則也容易產生挫敗感和焦燥情緒
在這一階段
最好用幾個簡單的段落對自己的系統作出描述
然後圍繞它們再進行擴充
添加一些
名詞
和
動詞
名詞
自然成為對象
而
動詞
自然成為要整合到對象接口中的
方法
只要親自試著做一做
就會發現這是多麼有用的一個工具
有些時候
它能幫助你完成絕大多數的工作
盡管仍處在初級階段
但這時的一些日程安排也可能會非常管用
我們現在對自己要構建的東西應該有了一個較全面的認識
所以可能已經感覺到了它大概會花多長的時間來完成
此時要考慮多方面的因素
如果估計出一個較長的日程
那麼公司也許決定不再繼續下去
或者一名主管已經估算出了這個項目要花多長的時間
並會試著影響你的估計
但無論如何
最好從一開始就草擬出一份
誠實
的時間表
以後再進行一些暫時難以作出的決策
目前有許多技術可幫助我們計算出准確的日程安排（就象那些預測股票市場起落的技術）
但通常最好的方法還是依賴自己的經驗和直覺（不要忘記
直覺也要建立在經驗上）
感覺一下大概需要花多長的時間
然後將這個時間加倍
再加上
％
你的感覺可能是正確的
也許
能在那個時間裡完成
但
加倍
使那個時間更加充裕
％
的時間則用於進行最後的推敲和深化
但同時也要對此向上級主管作出適當的解釋
無論對方有什麼抱怨和修改
只要明確地告訴他們
這樣的一個日程安排
只是我的一個估計！
階段如何構建？ 在這一階段
必須拿出一套設計方案
並解釋其中包含的各類對象在外觀上是什麼樣子
以及相互間是如何溝通的
此時可考慮采用一種特殊的圖表工具
統一建模語言
（UML）
請到去下載一份UML規格書
作為第
階段中的描述工具
UML也是很有幫助的
此外
還可用它在第
階段中處理一些圖表（如流程圖）
當然並非一定要使用UML
但它對你會很有幫助
特別是在希望描繪一張詳盡的圖表
讓許多人在一起研究的時候
除UML外
還可選擇對對象以及它們的接口進行文字化描述（就象我在《Thinking in C++》裡說的那樣
但這種方法非常原始
發揮的作用亦較有限
我曾有一次非常成功的咨詢經歷
那時涉及到一小組人的初始設計
他們以前還沒有構建過OOP（面向對象程序設計）項目
將對象畫在白板上面
我們談到各對象相互間該如何溝通（通信）
並刪除了其中的一部分
以及替換了另一部分對象
這個小組（他們知道這個項目的目的是什麼）實際上已經制訂出了設計方案
他們自己
擁有
了設計
而不是讓設計自然而然地顯露出來
我在那裡做的事情就是對設計進行指導
提出一些適當的問題
嘗試作出一些假設
並從小組中得到反饋
以便修改那些假設
這個過程中最美妙的事情就是整個小組並不是通過學習一些抽象的例子來進行面向對象的設計
而是通過實踐一個真正的設計來掌握OOP的竅門
而那個設計正是他們當時手上的工作！
作出了對對象以及它們的接口的說明後
就完成了第
階段的工作
當然
這些工作可能並不完全
有些工作可能要等到進入階段
才能得知
但這已經足夠了
我們真正需要關心的是最終找出所有的對象
能早些發現當然好
但OOP提供了足夠完美的結構
以後再找出它們也不遲
階段開始創建 你可能是程序員
現在進入的正是你可能最感興趣的階段
由於手頭上有一個計劃——無論它有多麼簡要
而且在正式編碼前掌握了正確的設計結構
所以會發現接下去的工作比一開始就埋頭寫程序要簡單得多
而這正是我們想達到的目的
讓代碼做到我們想做的事情
這是所有程序項目最終的目標
但切不要急功冒進
否則只有得不償失
根據我的經驗
最後先拿出一套較為全面的方案
使其盡可能設想周全
能滿足盡可能多的要求
給我的感覺
編程更象一門藝術
不能只是作為技術活來看待
所有付出最終都會得到回報
作為真正的程序員
這並非可有可無的一種素質
全面的
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25517.html
