再談建模

在如何成為一個優秀的程序員二,我談到了建模.在這裡我再補充些想法.
在前面部分我談到建模中一個常見的錯誤傾向: 試圖建立起一個能夠預知未來,包容萬象的模塊體系.這種好高騖遠的建模方式常常導致三個後果:
1 開發工作被無限期拖延;
2 模塊層次過於複雜,維護十分困難;
3 軟件結構遠遠偏離了今天的實際需要,模塊之間的訪問和調用往往需要通過許多不必要的環節,直接影響了軟件的運行速度.

接下來,我想談談建模中的另一個錯誤傾向:對現存設計模式的生搬硬套.上世紀九十年代Erich Gamma等人將設計模式(design pattern)理論引入了計算機科學領域.1995年Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides共 同撰寫了:" Design Patterns -- Elements of Reusable Object-Oriented Software "一書.它的四位作者也被戲稱為"四人幫"(Gang of Four 簡稱GoF).書中共收錄了23個設計模式.此書一出,軟件工業界如獲至寶.很多人開口GoF閉口還是GoF.軟件設計模式幾乎成為計算機系學生最重要的 必修課之一.記得當時很流行的一種看法是:優秀的學生去建模,平庸的學生去編碼.

事情真的這麼簡單嗎?是不是只要把"四人幫"給我們提供的模式背得滾瓜爛熟,現實中的問題便可迎刃而解?

首 先我想從我個人的學習經驗出發來談談我對這些設計模式的看法.我最初讀GoF的書,是學生時代.當時沒有多少編程經驗,費了很大力氣囫圇吞棗地把全書啃 完.但始終無法對這些設計模式有個清晰的認識,甚至覺得各種模式之間有很多互相矛盾之處,真的運用起來十分困難.當時正好實驗室需要編寫一個數據壓縮程 序.我便趁機現炒現賣,想用自己剛學到的理論來指導實踐.該數據壓縮軟件可以處理4種類型的數據:double, float, int, string.於是我便想當然地建立了四個模塊:doubleCompress, floatCompress, intCompress, stringCompress.並且根據當時學的理論知識,運用了抽象工廠模式,單例模式等等.但事實上,不同類型的數據壓縮的算法之間有着千絲萬縷的關 系,結果導致我的模塊之間的關係複雜,邏輯十分混亂.項目開發結果也就可想而知了.

後來有了一定的工作經驗,特別是在進行了大量的編碼之 後,再重讀GoF的設計模式,感覺就完全不同了.不但對書中提到的各種設計模式的利弊有了清楚的認識,而且不無驚喜地發現,在具體的開發實踐中,我已經不 知不覺地用上了許多GoF的設計模式了.那麼我是如何在不自覺中找到這些設計模式的呢?回想起來,其實很簡單.在開發和維護軟件的過程中,我常常遇到一些 問題,比方說有些編碼被多次重複使用;又比如由於模塊之間的關係混亂,導致對某些模塊的訪問十分繁瑣,且沒有邏輯等等.這些問題不但使得軟件的維護變得十 分困難,而且大大增加了軟件出現漏洞的可能性.當這些問題變得越來越不可容忍的時候,我就想也許應該從軟件結構上入手,換一種思維方式,重新設計模塊.通 過這樣一個不斷思考優化改進的過程,GoF的設計模式便不請自來了.因此我認為優秀的設計模式是在對具體問題的不斷思考,日積月累的編碼實踐中得來的.因 此這裡我要再次重複我曾經提到的觀點:建模不應該是程序開發初始階段的一個單獨僵硬的板塊,它應該貫穿於整個開發過程中.建模應該始終和軟件所要處理的具 體問題緊密聯繫在一起.一切從問題出發.尋找最簡單最合理的設計模式.