我使用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本身 造成的。
