【正文】 iate when you have a wellunderstood problem.) At least agree that this is the plan. 英文翻譯 原文 第 13 頁 (共 21 頁 ) You might also decide at this phase that some additional process structure is necessary, but not the whole nine yards. Understandably, some programmers like to work in “vacation mode,” in which no structure is imposed on the process of developing their work。向類中添加方法總是容易的，但隨著時間推移，從類中刪除方法可就困難了。需要做決定的時候，可以使用 Ockham 的 剃刀法則：考慮最簡單的選擇，因為簡單的類總是最好的。 (5) 保持簡單。類可以將問題分解，并有助于對無序和混亂的狀態(tài)進(jìn)行控制。做出可以運行的某些東西，才可以證明或者反駁你的設(shè)計。 在學(xué)習(xí)的過程中，隨時可能了解某些事情。如果這些類已經(jīng)有了，那么這將是個簡單的項目。 對象開發(fā)指南 在思考如何開發(fā)類的時候，下列步驟是一些具體的指導(dǎo)： (1) 為一個特定問題生成一個類，然后在解決其他問題的過程中，讓這個類成長并且 成熟。無論如何，別指望系統(tǒng)中的多數(shù)對象都被設(shè)計為可重用的，因為完全可以接受大多數(shù)的對象是系統(tǒng)相關(guān)的。如果某人在全新的場景中重用某個類，可能會發(fā)現(xiàn)該類的某些缺陷。 (5) 對象 重用。有了這些信息，就可以通過添加新的類或者類的層次，來重新構(gòu)造部分的系統(tǒng)。 (4) 系統(tǒng)擴(kuò)展。與其它對象相互通信和互聯(lián)的需求，可能會改變你所需要的類或者需要新的類。如前所述，更多的需求要在稍后的階段才顯現(xiàn)出來。對象內(nèi)部的 需求可能需要其他類的支持。 (2) 對象的組合。通過類之間的共性，可以確定基類。通過找出外部因素和系統(tǒng)邊界、重復(fù)元素、以及最小的概念單元，就能夠發(fā)現(xiàn)對象。 英文翻譯 譯文 第 8 頁 (共 21 頁 ) (1) 發(fā)現(xiàn)對象。針對特定類型程序的模式都是在一遍遍與問題對抗的過程中浮現(xiàn)出來的 (這是《 Thinking in Patterns(with Java)》一書的主題，可由 取得 )。這種觀點很有幫助，因為，當(dāng)你不再期望立刻就能達(dá)到完美，反而可以認(rèn)識到：對對象行為和外貌的理解，會隨著時間流逝而發(fā)生。事實上，對象的設(shè)計可劃分為五個階段，貫穿整個程序開發(fā)過程。重要的是，你最終能找到所有的對象。然而總會有遺漏，要到第三階段才能發(fā)現(xiàn)。對于數(shù)據(jù)為主導(dǎo)因素的系統(tǒng)或子系統(tǒng) (例如數(shù)據(jù)庫 )，可能還需要描述數(shù)據(jù)結(jié)構(gòu)的圖。有時候它們很管用。 UML 的替代方案是，以文字描述對象和接口，或者依賴程序語言，即代碼本身。你可以不用 UML，不過它確實很有幫助，特別是如果你想在墻上掛一張圖，讓大家都專注于對它進(jìn)行思考的時候。而且不是通過抽象的示例，而是通過自己做設(shè)計學(xué)會的，在那一刻，這對他們才是最感興趣的，因為這樣的設(shè)計是屬于他們的。我所做的只是引導(dǎo)這個過程，問恰當(dāng)?shù)膯栴}，提取出所有的假設(shè)，再基于開發(fā)團(tuán)隊的反饋去修改這些假設(shè)。我在白板上管理所有的“ CRC 卡”，這很有效。那是個從未做過 OOP 項目的團(tuán)隊。所有的用例都分析過之后，你就有了一份相當(dāng)完整的初始設(shè)計。通過模擬場景，每次解決一個“場景”，決定要向哪些不同的對象發(fā)送哪些消息。尤其是在團(tuán)體中不用電腦進(jìn)行實時交流的時候。 CRC卡的思想就是幫助你形成最初的設(shè)計，對問題有全面的了解，然后再改進(jìn)你的設(shè)計。如果對于某個類，一張卡片的信息無法滿足你的需要，那么這個類就太復(fù)雜了 (或者是你考慮的太仔細(xì)了，或者是應(yīng)該多創(chuàng)建幾個類 )。 你也許覺得卡片應(yīng)該更大一些，因為你想在上面記錄所有的信息。協(xié)作關(guān)系還應(yīng)該考慮這個類的聽眾。通?？梢詮念惖姆椒锌偨Y(jié)獲得 (因為在好的設(shè)計中，那些方法的名字應(yīng)該是描述性的 )，但也不排除還有別的成分。這很重要，應(yīng)該做到讓人望文生義，一眼就能猜到類的功能。它的價值在部分程度上在于它沒什么技術(shù)：做一些 35 的卡片，然后在上面填寫。 階段 2：如何構(gòu)建？ 在這個階段，你必須完成一個設(shè)計，它描述了各個類的模樣，以及它們之間交互。乘上兩倍是為了把事情做得更像樣，最后百分之十則用在潤飾處理上。先憑直覺來估計所需時間，然后乘以兩倍，最后再加上百分之十。不過，最好一開始就能有一個誠實的進(jìn)度安排，并盡早做出這個困難的決定。如果你把 進(jìn)度估計的過長，那么公司可能會決定不做此項目 (這樣，公司的資源可以用在更合理的地方 )?，F(xiàn)在，你對你要做的東西應(yīng)該有了一定的了解，因此你能夠大致猜到這項工作要做多久。 用例與參與者之間的邊界能夠指出用戶接口之存在，但它并不定義任 何用戶接口。動詞可以表示角色與用例間的交互，并說明用例中的步驟。 如果你真的陷入了困境，可以使用粗略的近似工具，來啟動此階段的工作：用很少的段落來描述系統(tǒng)，然后找出名詞與動詞。你可能無法一次就理清所有事情，但是沒關(guān)系，所有事情都會及時顯露出來。專注于用例的好處在于，它總可以令你回到問題的本質(zhì)，不至于轉(zhuǎn)到對工作不重要的事情上。例如：通過確定用戶與系統(tǒng)間的所有交互，用例可以生成需求說明。 即使底層系統(tǒng)確實十分復(fù)雜，用例也不需要很復(fù)雜。參與者與用例之間的連線表示交互 。方框表示系統(tǒng)邊界。這些 “情況”都被“場景 (scenario)”，用例則被看作場景的集合。用例能夠找出系統(tǒng)的關(guān)鍵特征，提示出一些將要用到的基本的類。 此階段我們要完成什么任務(wù)呢？注意力必須集中于問題的核心：確定系統(tǒng)要作什么。這樣做不僅征求了每個人的意見，也促使了團(tuán)隊達(dá)成一致。有些限制可能需要你擴(kuò)充這些文檔，但是初始文檔應(yīng)該保持小而簡練。理想情況是只需將其以列表方式列出，配合基本的圖片即可。系統(tǒng)說明書是從頂層探討問題，在某種意義上，它說明此項目是否可以做，要做多久。系統(tǒng)說明書就是要“描述程序需要做什么（不是如何做）才能滿足需求”。當(dāng)然，這些文檔的用意是好的。這正是令人不知所措的地方。有一種更為實用的模型，它并不關(guān)心你的解決方案，只關(guān)心問題的描述：“飛機(jī)抵達(dá)、缺客、檢修、登機(jī)、然后離港。例如對于一個空中交通控制系統(tǒng)，你可能將“中心思想”鎖定在你要開發(fā)的系統(tǒng)本身：“航管塔臺記錄飛機(jī)行蹤”。 “中心思想”很重要，它為項目設(shè)定了基調(diào)，也就是任務(wù)描述。就像好萊塢電影的“中心思想”，只用一兩句話來描述。 任務(wù)描述 開發(fā)任何系統(tǒng)，無論多復(fù)雜，都有一個基本目的：它所處的行業(yè)、它所需要滿足的基本需求。但我還是將 我的工作結(jié)構(gòu)化了，雖然只是出于半自覺狀態(tài)。 在我開始研究小說結(jié)構(gòu)的時候（因為我希望某天我能寫一本小說），我對于規(guī)劃小說結(jié)構(gòu)的思想有些抗拒，我覺得，直接把故事寫到紙上就是最好的辦法。并且每達(dá)到一個里程碑，都是對你所獲得的一點成就的激勵，使你不至于被“完成整個項目”這樣一個單一的目標(biāo)給弄得暈頭轉(zhuǎn)向。“能完成的時候，它自然就完成了。 在這一階段，你可能還要決定采用某些必要的附加處理結(jié)構(gòu)，但這并不是完整的結(jié)構(gòu)。聽起來這很簡單（事實上，所有的事情聽起來都很簡單），然而在開始編碼之前，人們經(jīng)常無法做出這樣的決定。 這個過程可以分為 5 個階段，以及僅僅是對所采用的結(jié)構(gòu) 做最初的確定的階段 0。請銘記于心，你要嘗試去發(fā)現(xiàn)的是： (1) 要使用對象是什么？（如何將項目劃分為各個構(gòu)件？） (2) 這些對象的接口是什么？（你需要發(fā)送什么消息給每個對象？） 如果確定了對象和接口，那么就可以開始編寫程序了。因此，第一次快速開發(fā)，不僅生 成了對下一次分析、設(shè)計與開發(fā)都有用的信息，同時也生成了代碼的根基。 我們常常聽人建議“構(gòu)建一個，然后扔掉”。匆忙地進(jìn)行初步開發(fā)，看起來似乎增加了風(fēng)險，但是對于外卡型項目，卻是降低了它們的風(fēng)險，因為你可以盡早地發(fā)現(xiàn)某種方法是否可行。因為在分析階段，你沒有足夠的信息來解決此類問題。其中包含一個或多個“外卡因素”，這些因素并沒有已知的很好的解法，因此對它們的研究就很有必要。本章討論的編程問題，我稱之為“外卡（ wildcard）”的多樣性。但是 DBMS 這一類問題，我們已經(jīng)描述了理解得很好了。過去使用的是過程型編程語言，在設(shè)計與實現(xiàn)某個系統(tǒng)之前，開發(fā)團(tuán)隊會仔細(xì)地進(jìn)行分析，理解每一個細(xì)節(jié)。因此，快速地完成分析與設(shè)計階段，并且對開發(fā)的系統(tǒng)進(jìn)行測試才是至關(guān)重要的。 英文翻譯 譯文 第 2 頁 (共 21 頁 ) 這很容易使人迷失，從而陷入“分析癱瘓”，使你感覺無法取得進(jìn)展，因為你無法確定當(dāng)前階段的每一個細(xì)節(jié)。但是請記住，多數(shù)工程并屬于這一范疇，我們通常只需采用某種方法論所推薦的一個相對較小的子集就可以得到成功的分析和設(shè)計 。這很容易做到。但如果你對自己的生產(chǎn)率與程序的開發(fā)方式不滿意，那么你就應(yīng)該考慮采用某種形式化的方法論，或者從多種形式化的方法論中選擇多個部分加以應(yīng)用。它可 能是你自己的方法論，也許你根本就是無意識的，但是你所經(jīng)歷的處理過程就是你創(chuàng)建的方法論。 正確理解“方法論”這個術(shù)語也很重要，它通常顯得太隆重了，并且總是給人以太多的希望。這實際上降低了對復(fù)雜的方法論的需求程度。所以，在采用某種方法論之前，弄清楚它能解決什么問題就顯得十分重要。本節(jié)將讓你體會在采用某種方法論時你將能夠達(dá)到的目標(biāo)。 方法學(xué) 方法學(xué) （ methodology,有時直接稱之為“方法 (method)”）是一套用以降解編程問題復(fù)雜性的過程與啟發(fā)。現(xiàn)在你已經(jīng)理解了對象的概念，那么在學(xué)會以面向?qū)ο蟮姆绞剿伎紗栴}之后，你就能夠充分利用 OOP帶來的所有優(yōu)勢，創(chuàng)造出“好”的設(shè)計了。英文翻譯 譯文 第 1 頁 (共 21 頁 ) 中文： 分析與設(shè)計 面向?qū)ο笫且环N全新的編程思考方式。 第一次了解如何處理一個 OOP 工程時，多數(shù)人都會感到困難。本章將介紹分析與設(shè)計的思想，以及一些方法，以幫助你在適度的時間內(nèi)開發(fā)出良好的面向?qū)ο蟮某绦?。自從面向?qū)ο缶幊堂媸酪詠?，已?jīng)系統(tǒng)地提出了許多種OOP 方 法論。 方法論是由許多經(jīng)驗積累而成的，特別是在 OOP 中尤為如此。對于 Java 而言，這尤其正確， Java（與 C 相比）是用來降低程序表達(dá)時的復(fù)雜度的編程語言。對比過程型編程語言，在使用 Java 時，簡單的方法論就足以解決大多數(shù)問題。其實設(shè)計與編程時所做的事情，就是方法論。如果它很有效，那么只需要對它作小小的調(diào)整，就能將它應(yīng)用于 Java。 在你經(jīng)歷整個開發(fā)過程時，最重要的一點是：不要迷失。大多數(shù)分析與設(shè)計方法論都試圖解決最大型的問題。但是某些類型的處理過程，無論它們怎樣小或者怎樣受限制，通常也都應(yīng)該采用某種比直接開始編碼要好得多的方式。記住，無論你做了多少分析，總有些問題不到設(shè)計階段是無法發(fā)現(xiàn)的，而更多的問題直到編碼階段，或者程序運行時才會暴露出來。 這一點很值得強(qiáng)調(diào)。當(dāng) 然，開發(fā)數(shù)據(jù)庫管理系統(tǒng)（ DBMS）時，必須徹底理解用戶的需求。在許多這樣的程序中，數(shù)據(jù)庫的結(jié)構(gòu)就是問題的核心。要解決此類問題，可不是簡單地修改某個著名的解決方案就可以的。如果在進(jìn)入設(shè)計與實現(xiàn)階段之前，你試圖徹底分析外卡問題，那么其結(jié)果只能陷入分析癱瘓。 解決這樣的問題需要迭代重復(fù)整個過程，需要采取冒險的行為（這是有意義的，因為你正在嘗試解決一些新問題，它們具有更高的潛在回報）。產(chǎn)品開發(fā)其實就是風(fēng)險管理。使用 OOP，你可能仍需丟棄一部分，但是由于代碼以類的形式進(jìn)行了封裝，所以在第一次開發(fā)過程中肯定會產(chǎn)生一些有用的類，以及一些對于系統(tǒng)設(shè)計有價值的想法，這些可不該被丟棄掉。 也就是說，如果你選擇的方法論包含大量的細(xì)節(jié)，并且建議采用多個步驟與文檔，那么就仍然難以了解何時應(yīng)該停止。由于各種各樣的原因，你可能還需要更多的描述與文檔才能開始編程，但是這兩者缺一不可。 階段 0：制定計劃 英文翻譯 譯文 第 3 頁 (共 21 頁 ) 首先你得決定，在開發(fā)過程中需要哪些步驟。如果你的計劃是“直接開始編碼”，那也可以（當(dāng)你對問題很清楚時，這樣的決定也是合適的），至少這也算是有計劃。有些程序員喜歡以“度假的方式”工作，他們對開發(fā)過程不限制任何結(jié)構(gòu)，這是可以理解的?！边@自然討人喜歡，但是我發(fā)現(xiàn)，如 果在開發(fā)過程中劃分一些里程碑，將有助于集中精力。此外，將項目劃分為許多可以一口吃掉的小塊，也可以使得項目不那么嚇人（增加里程碑提供了更多慶祝的機(jī)會）。但是，后來我認(rèn)識到，當(dāng)我撰寫有關(guān)計算機(jī)的文章時，由于我已經(jīng)很清楚它的結(jié)構(gòu)了，所以才不需要考慮很多。所以，即便你的計劃是直接開始編碼，其實在對某些問題的問答之間，你已經(jīng)不知不覺地經(jīng)歷了此階段。只有拋開用戶界面、與硬件相關(guān)或系統(tǒng)相關(guān)的細(xì)節(jié)、算法、效率等問題，你才能找出簡單而直接的系統(tǒng)核心。這種純粹的描述就是項目的起點。不必強(qiáng)求第一次就要描述得正確無誤（在完全將問題弄清 楚之前，你可能已經(jīng)進(jìn)入項目的下一階段了），但是應(yīng)該不斷努力，直到你感覺正確了為止。但是當(dāng)你將系統(tǒng)縮小，應(yīng)用到很小的機(jī)場時，會發(fā)生什么呢？也許那里只有人工控制，根本沒有航管塔臺?！? 英文翻譯 譯文 第 4 頁 (共 21 頁 ) 階段 1：做什么？ 在上一代的程序設(shè)計中（所謂過程型設(shè)計 procedural design），將此階段稱為“生成需求分析與系統(tǒng)說 明書”。那些名頭嚇人的文檔，本身就是一項大工程。需求分析就是“列出指導(dǎo)方針，使我們知道項目何時完成，并且使用戶滿