zongxing

我使用OO技術第一次設計軟件的時候，犯了一個設計者所能犯的所有錯誤。那是一個來自國外的外包項目，外方負責功能設計，我們公司負責程序設計、編碼和測試。

第一個重要的錯誤是，我沒有認真的把設計說明書看明白。功能點設計確實有一些問題，按照他們的設計，一個重要的流程是無法實現的。于是我在沒有與投資方溝通的情況下，擅自改動了設計，把一個原本在Linux系統上開發的模塊改到了Windows系統上。結果流程確實是實現了，但是很不幸，根本不符合他們的需要，比起原先的設計差的更多。在詢問了這個流程的設計意圖之后，我也清楚了這一點。對方的工程師承認了錯誤，但是問題是：“為什么不早說啊，我們都跟領導講過了產品的構架，也保證了交貨時間了，現在怎么去說啊？”。他們設計的是一個蘋果，而我造了一個桔子出來。最后和工程師商議的結果是：先把桔子改成設計書上的蘋果，按時交貨，然后再悄悄的改成他們真正需要的香蕉。的這時候距離交貨的時間已經不足三天了，于是我每天加班工作到天明，把代碼逐行抽出來，用gcc編譯調試。好在大部分都是體力活，沒有什么技術含量，即使在深夜大腦半休眠的情況下仍然可以接著干。

項目中出現的另外一個錯誤是：我對工作量的估計非常的不準確。在第一個階段的時候，按照功能設計說明書中的一個流程，我做了一個示例，用上了投資方規定的所有的技術。當我打開瀏覽器，看到頁面上出現了數據庫里的“Tom，Jerry，王小帥”，就愉快的跑到走廊上去呼吸了一口新鮮空氣，然后樂觀的認為：設計書都已經寫好了，示例也做出來了，剩下的事情肯定就象砍瓜切菜一樣了。不就是把大家召集起來講講設計書，看看示例，然后撲上去開工，然后大功告成。我為每個畫面分配的編碼工作量是三個工作日。結果卻是，他們的設計并不完美，我的理解也并不正確，大家的思想也并不一致。于是我天天召集開會，朝令夕改，不斷返工。最后算了一下，實際上寫完一個畫面用的時間在十個工作日以上。編碼占用了太多的時間，測試在匆忙中草草了事，質量……能掩蓋的問題也就只好掩蓋一下了，性能更是無暇顧及了。

還有一個方面的問題是出在技術上的，這方面是我本文要說的重點。按照投資方的方案，系統的主體部分需要使用J2EE框架，選擇的中間件是免費的JBoss。再加上Tomcat作為Web服務器，Struts作為表示層的框架。他們對于這些東西的使用都是有明確目的，但是我并不了解這些技術。新手第一次進行OO設計，加上過多的新式技術，于是出現了一大堆的問題。公司原本安排了一個牛人對我進行指導，他熟悉OO設計，并且熟悉這些開源框架，曾熟讀Tomcat和Struts源代碼。可是他確實太忙，能指導我的時間非常有限。

投資方發來設計書以后，很快就派來了兩個工程師對這個說明書進行講解。這是一個功能設計說明書，包括一個數據庫設計說明書，和一個功能點設計說明。功能點說明里面敘述了每一個工作流程，畫面設計和數據流程。兩位工程師向我們簡單的說明了產品的構想，然后花了一個多星期的時間十分詳細的說明了他們的設計，包括數據表里每一個字段的含義，畫面上每一個控件的業務意義。除了這些功能性的需求以外，他們還有一些技術上的要求。

為了減少客戶的擁有成本，他們不想將產品綁定在特定的數據庫和操作系統上，并且希望使用免費的平臺。于是他們選擇了Java作為開發語言，并且使用了一系列免費的平臺。選用的中間件是JBoss，使用Entity Bean作為數據庫訪問的方式。我們對Entity Bean的效率不放心，因為猜測他運用了大量的反射技術。在經過一段時間的技術調查之后，我決定不采用Entity Bean，而是自己寫出一大堆的Value Object，每個Value Object對應一個數據庫表，Value Object里面只有一些setter和getter方法，只保存數據，不做任何事情。Value Object的屬性與數據庫里面的字段一一對應。與每個Value Object對應，做一個數據表的Gateway，負責把數據從數據庫里面查出來塞到這些Value Object里面，也負責把Value Object里面的數據塞回數據庫。

按照這樣的設計，需要為每一個數據表寫一個Gateway和一個Value Object，這個數量是比較龐大的。因此我們做了一個自動生成代碼的工具，到數據庫里面遍歷每一個數據表，然后遍歷表里面的每一個字段，把這些代碼自動生成出來。

這等于自己實現了一個ORM的機制。當時我們做這些事情的時候，ORM還是一個很陌生的名詞，Hibernate這樣的ORM框架還沒聽說過。接著我們還是需要解決系統在多種數據庫上運行的問題。Gateway是使用JDBC連接數據庫的，用SQL查詢和修改數據的。于是問題就是：要解決不同數據庫之間SQL的微小差別。我是這樣干的：我做了一個SqlParser接口，這個接口的作用是把ANSI SQL格式的查詢語句轉化成各種數據庫的查詢語句。當然我沒必要做的很全面，只要支持我在項目中用到的查詢方式和數據類型就夠了。然后再開發幾個具體的Parser來轉換不同的數據庫SQL格式。

到這個時候，數據庫里面的數據成功轉化成了程序里面的對象。非常好！按道理說，剩下的OO之路就該順理成章了。但是，很不幸，我不知道該怎樣用這些Value Object，接下來我就懷著困惑的心情把過程式的代碼嫁接在這個OO的基礎上了。

我為每一個畫面設計出了一個Session Bean，在這個Session Bean里面封裝了畫面所關聯的一切業務流程，讓這個Session Bean調用一大堆Value Object開始干活。在Session Bean和頁面之間，我沒有讓他們直接調用，因為據公司的牛人說：“頁面直接調用業務代碼不好，耦合性太強。”這句話沒錯，但是我對“業務代碼”的理解實在有問題，于是就硬生生的造出一個Helper來，阻擋在頁面和Session Bean中間，充當了一個傳聲筒的角色。

于是在開發中就出現了下面這副景象：每當設計發生變更，我就要修改數據庫的設計，用代碼生成工具重新生成Value Object，然后重新修改Session Bean里面的業務流程，按照新的參數和返回值修改Helper的代碼，最后修改頁面的調用代碼，修改頁面樣式。

實際情況比我現在說起來復雜的多。比如Value Object的修改，程序規模越來越大以后，我為了避免出現內存的大量占用和效率的下降，不得不把一些數據庫查詢的邏輯寫到了Gateway和Value Object里面，于是在發生變更的時候，我還要手工修改代碼生成工具生成的Gateway和Value Object。這樣的維護十分麻煩，這使我困惑OO到底有什么好處。我在這個項目中用OO方式解決了很多問題，而這些問題都是由OO本身造成的。

另一個比較大的問題出在Struts上。投資方為系統設計了很靈活的界面，界面上的所有元素都是可以配置出來，包括位置、數據來源、讀寫屬性。并且操作員的權限可以精確到每一個查看、修改的動作，可以控制每一個控件的讀寫操作。于是他們希望使用Struts。Struts框架的每一個Action恰好對應一個操作，只需要自己定義Action和權限角色的關系，就可以實現行為的權限控制。但是我錯誤的理解了Struts的用法，我為每一個頁面設計了一個Action，而不是為每一個行為設計一個Action，這樣根本就無法做到他們想要的權限控制方式。他們很快發現了我的問題，于是發來了一個說明書，向我介紹Struts的正確使用方式。說明書打印出來厚厚的一本，我翻了一天，終于知道了錯在什么地方。但是一大半畫面已經生米煮成熟飯，再加上我的Session Bean里面的流程又是按畫面來封裝的，于是只能改造小部分能改造的畫面，權限問題另找辦法解決了。

下面就是這個系統的全貌，場面看上去還是蔚為壯觀的：

系統經歷過數次較大的修改，這個框架不但沒有減輕變更的壓力，反而使得變更困難加大了。到后來，因為業務流程的變更的越來越復雜，現有流程無法修改，只得用一些十分曲折的方式來實現，運行效率越來越低。由于結構過于復雜，根本沒有辦法進行性能上的優化。為了平衡效率的延緩，不得不把越來越多的Value Object放在了內存中緩存起來，這又造成了內存占用的急劇增加。到后期調試程序的時候，服務器經常出現“Out of memory”異常，各類對象龐大繁多，系統編譯部署一次需要10多分鐘。投資方原先是希望我們使用JUnit來進行單元測試，但是這樣的流程代碼測試起來困難重重，要花費太多的時間和人手，也只得作罷。此外他們設計的很多功能其實都沒有實現，并且似乎以后也很難再實現了。設計中預想的很多優秀特點在這樣框架中一一消失，大家無奈的接受一個失望的局面。

在我離開公司兩年以后，這個系統仍然在持續開發中。新的模塊不斷的添加，框架上不斷添加新的功能點。有一次遇到仍然在公司工作的同事，他們說：“還是原來那個框架，前臺加上一個個的JSP，然后后臺加上一個個的Value Object，中間的Session Bean封裝越來越多的業務流程。”

我的第一個OO系統的設計，表面上使用了OO技術，實際上分析設計還是過程主導的方式。設計的時候過多、過早、過深入的考慮了需要做哪些畫面，畫面上應該有哪些功能點，功能點的數據流程。再加上一個復雜的OO框架，名目繁多的對象，不僅無法做到快速的開發，靈活的適應需求的變化，反而使系統變得更加復雜，功能修改更加的麻煩了。

在面條式代碼的時代，很多人用匯編代碼寫出了一個個優秀的程序。他們利用一些工具，或者共同遵守一些特別的規約，采用一致的變量命名方式，規范的代碼注釋，可以使一個龐大的開發團隊運行的井井有條。人如果有了先進的思想，工具在這些人的手中就可以發揮出超越時代的能量。而我設計的第一個OO系統，恰好是一個相反的例子。

實際上，面向對象的最獨特之處，在于他分析需求的方式。按照這樣的方式，不要過分的糾纏于程序的畫面、操作的過程，數據的流程，而是要更加深入的探索需求中的一些重要概念。下面，我們就通過一個實例看一看，怎樣去抓住需求中的這些重要概念，并且運用OO方法把他融合到程序設計中。也看看OO技術是如何幫助開發人員控制程序的復雜度，讓大家工作的更加簡單、高效。

我們來看看一個通信公司的賬務系統的開發情況。最開始，開發人員找到電信公司的職員詢問需求的情況。電信公司的職員是這樣說的：

“賬務系統主要做這樣幾件事情：每個月1日凌晨按照用戶使用情況生成賬單，然后用預存沖銷這個賬單。還要受理用戶的繳費，繳費后可以自動沖銷欠費的賬單，欠費用戶繳清費用之后要發指令到交換上，開啟他的服務。費用繳清以后可以打印發票，發票就是下面這個樣子。”

經過一番調查，開發人員設計了下面幾個主要的流程：

1、 出賬：根據一個月內用戶的消費情況生成賬單；

2、 銷賬：沖銷用戶賬戶上的余額和賬單；

3、 繳費：用戶向自己的賬戶上繳費，繳清欠費后打印發票。

弄清了流程，接著就設計用戶界面來實現這樣的流程。下面是其中一個數據查詢界面，分為兩個部分：上半部分是繳費信息，記錄了用戶的繳費歷史；下半部分是賬單信息，顯示賬單的費用和銷賬情況。

界面上的數據一眼看起來很復雜，其實結合出賬、繳費、銷賬的流程講解一下，是比較容易理解的。下面簡單說明一下。

繳費的時候，在繳費信息上添加一條記錄，記錄下繳費金額。然后查找有沒有欠費的賬單，如果有就做銷賬。沖抵欠費的金額記錄在“欠費金額”的位置。如果欠費時間較長，就計算滯納金，記錄在“滯納金”的位置上。沖銷欠費以后，剩余的金額記錄在“預存款”的位置上。“其他費用”這個位置是預留的，目前沒有作用。

每個月出賬的時候，在賬單信息里面加上一條記錄，記錄下賬單的應收和優惠，這兩部分相減就是賬單的總金額。然后檢查一下賬戶上有沒有余額，如果有就做銷賬。銷賬的時候，預存款沖銷的部分記錄在“預存劃撥”的位置，如果不足以沖抵欠費，賬單就暫時處于“未繳”狀態。等到下次繳費的時候，沖銷的金額再記錄到“新交款”的位置。等到所有費用繳清了，賬單狀態變成“已繳”。

銷賬的流程就這樣融合在繳費和出賬的過程中。

看起來一切成功搞定了，最重要的幾個流程很明確了，剩下的事情無疑就像砍瓜切菜一樣。無非是繞著這幾個流程，設計出其他更多的流程。現在有個小問題：打印發票的時候，發票的右側需要有上次結余、本次實繳、本次話費、本次結余這幾個金額。

上次結余：上個月賬單銷賬后剩下來的金額，這個容易理解；

本次結余：當前的賬單銷賬后剩下的金額，這個也不難；

本次話費：這是賬單的費用，還是最后一次完全銷賬時的繳費，應該用哪一個呢？

本次繳費：這個和本次話費有什么區別，他在哪里算出來？

帶著問題，開發者去問電信公司的職員。開發者把他們設計的界面指點給用戶看，向他說明了自己的設計的這幾個流程，同時也說出了自己的疑問。用戶沒有直接回答這個疑問，卻提出了另一個問題：

“繳費打發票這個流程并不總是這樣的，繳費以后不一定立刻要打印發票的。我們的用戶可以在銀行、超市這樣的地方繳話費，幾個月以后才來到我們這里打印發票。并且繳費的時間和銷賬的時間可以相距很長的，可以先繳納一筆話費，后面幾個月的賬單都用這筆錢銷賬；也可以幾個月都不繳費，然后繳納一筆費用沖銷這幾個賬單。你們設計的這個界面不能很好的體現用戶的繳費和消費情況，很難看出來某一次繳費是在什么時候用完的。必須從第一次、或者最后一次繳費余額推算這個歷史，太麻煩了。還有，‘預存劃撥’、‘新交款’這兩個概念我們以前從來沒有見過，對用戶解釋起來肯定是很麻煩的。”

開發人員平靜了一下自己沮喪（或憤怒）的心情，仔細想一想，這樣的設計確實很不合理。如果一個會計記出這樣的賬本來，他肯定會被老板開除的。

看起來流程要改，比先前設計的更加靈活，界面也要改。就好像原先蓋好的一棟房子忽然被捅了幾個窟窿，變得四處透風了。還有，那四個數值到底應該怎樣計算出來呢？我們先到走廊上去呼吸兩口新鮮空氣，然后再回來想想吧。

現在，讓我們先忘記這幾個變化多端的流程，花一點時間想一想最基本的幾個概念吧。系統里面最顯而易見的一個概念是什么呢？沒錯，是賬戶（Account）。賬戶可以繳費和消費。每個月消費的情況是記錄在一個賬單（Bill）里面的。賬戶和賬單之間是一對多的關系。此外，賬戶還有另一個重要的相關的概念：繳費（Deposit）。賬戶和繳費之間也是一對多的關系。在我們剛才的設計中，這些對象是這樣的：

這個設計看來有些問題，使用了一些用戶聞所未聞的概念（預存劃撥，新交款）。并且他分離了繳費和消費，表面上很清楚，實際上使賬單的查詢變得困難了。在實現一些功能的時候確實比較簡單（比如繳費和銷賬），但是另一些功能變得很困難（比如打印發票）。問題到底在什么地方呢？

涉及到賬務的行業有很多，最容易想到的也許就是銀行了。從銀行身上，我們是不是可以學到什么呢？下面是一個銀行的存折，這是一個委托收款的賬號。用戶在賬戶上定期存錢，然后他的消費會自動從這里扣除。這個情景和我們需要實現的需求很相似。可以觀察一下這個存折，存入和支取都是記錄在同一列上的，在支出或者存入的右側記錄當時的結余。

有兩次賬戶上的金額被扣除到0，這時候金額已經被全部扣除了，但是消費還沒有完全沖銷。等到再次存入以后，會繼續支取。這種記賬的方式就是最基本的流水賬，每一條存入和支出都要記錄為一條賬目（Entry）。程序的設計應該是這樣：

這個結構看上去和剛才那個似乎沒有什么不同，其實差別是很大的。上面的那個Deposit只是繳費記錄，這里的Entry是賬目，包括繳費、扣費、滯納金……所有的費用。銷賬扣費的過程不應該記錄在賬單中，而是應該以賬目的形式記錄下來。Account的代碼片段如下：

Entry有很多種類型（存入、支取、滯納金、贈送費），可以考慮可以為每一種類型創建一個子類，就像這樣：

搞成父子關系看起來很復雜、麻煩，并且目前也看不出將這些類型作為Entry的子類有哪些好處。所以我們決定不這樣做，只是簡單的把這幾種類型作為Entry的一個屬性。Entry的代碼片段如下：

Entry是一個枚舉類型，代碼如下：

下面的界面顯示的就是剛才那個賬戶的賬目。要顯示這個界面只需要調用Account的GetEntrees方法，得到所有的賬目，然后按時間順序顯示出來。這個界面上的消費情況就明確多了，用戶很容易弄明白某個繳費是在哪幾個月份被消費掉的。

并且，發票上的那幾個一直搞不明白的數值也有了答案。比如2005年6月份的發票，我們先看看2005年6月份銷賬的所有賬目（第六行、第八行），這兩次一共扣除73.66元，這個金額就是本次消費；兩次扣除之間存入200元，這個就是本次實繳；第五行的結余是17.66元，這就是上次結余；第八行上的結余是144元，這個就是本次結余。

用戶檢查了這個設計，覺得這樣的費用顯示明確多了。盡管一些措辭不符合習慣的業務詞匯，但是他們的概念都是符合的。并且上次還有一個需求沒有說：有時候需要把多個月份的發票合在一起打印。按照這樣的賬目表達方式，合并的發票數值也比較容易搞清楚了。明確了這樣的對象關系，實現這個需求其實很容易。

面向對象的設計就是要這樣，不要急于確定系統需要做哪些功能點和哪些界面，而是首先要深入的探索需求中出現的概念。在具體的流程不甚清楚的情況下，先把這些概念搞清楚，一個一個的開發出來。然后只要把這些做好的零件拿過來，千變萬化的流程其實就變得很簡單了，一番搭積木式的裝配就可以比較輕松的實現。

另一個重要的類型也漸漸清晰的浮現在我們的眼前：賬單（Bill）。他的代碼片段如下：

Bill類有兩個與滯納金有關的方法，這使開發者想到了原先忽略的一個流程：計算滯納金。經過與電信公司的確認，決定每個月進行一次計算滯納金的工作。開發人員寫了一個腳本，先得到系統中所有的欠費賬單，然后一一調用他們的CaculatePenalty方法。每個月將這個腳本執行一次，就可以完成滯納金的計算工作。

Bill對象中有賬戶的基本屬性和各級賬目的金額和銷賬的情況，要打印發票，只有這些數值是不夠的。還要涉及到上次結余、本次結余和本次實繳，這三個數值是需要從賬目中查到的。并且發票有嚴格的格式要求，也不需要顯示費用的細節，只要顯示一級和二級的費用類就可以了。應該把這些東西另外封裝成一個類：發票（Invoice）：

通信公司后來又提出了新的需求：有些賬號和銀行簽訂了托收協議，每個月通信公司打印出這些賬戶的托收單交給銀行，銀行從個人結算賬戶上扣除這筆錢，再把一個扣費單交給通信公司。通信公司根據這個扣費單沖銷用戶的欠費。于是開發人員可以再做一個托收單（DeputyBill）：

賬單中的GetFee方法的返回值類型是Fee，Fee類型包含了費用的名稱、金額和他包含的其他費用。例如下面的情況：

我們可以用這樣的一個類來表示費用（Fee），一個費用可以包含其他的費用，他的金額是子費用的金額和。代碼片段如下：

現在開發者設計出了這么一堆類，構成軟件系統的主要零件就這么制造出來了。下面要做的就是把這些零件串在一起，去實現需要的功能。OO設計的重點就是要找到這些零件。就像是設計一輛汽車，僅僅知道油路、電路、傳動的各項流程是不夠的，重要的是知道造一輛汽車需要先制造哪些零件。要想正確的把這些零件設計出來不是一件容易的事情，很少有開發者一開始就了解系統的需求，設計出合理的對象關系。根本的原因在于領域知識的貧乏，開發者和用戶之間也缺乏必要的交流。很多人在軟件開發的過程中才漸漸意識到原來的設計中存在一些難受的地方，然后探索下去，才知道了正確的方式，這就是業務知識的一個突破。不幸的是，當這個突破到來的時候，程序員經常是已經忙得熱火朝天，快把代碼寫完了。要把一切恢復到正常的軌道上，需要勇氣，時間，有遠見的領導者，也需要有運氣。