分析和設計

2019-11-18 12:09:44

字體：大中小

來源：轉載

供稿：網友

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

上一篇：用句柄操縱對象

下一篇：對象的創建和存在時間