很久以來我們一直追求象搭積木一樣,象生產(chǎn)工業(yè)產(chǎn)品一樣去生成我們的軟件. 在面向?qū)ο蟪鍪乐H我們以為我們找到了答案, 當它給我?guī)硎臅r候,我們又將希望寄于組件技術, 然而迄今為止我們?nèi)匀粺o法實現(xiàn)我們的夢想.
面向?qū)ο蠹夹g在Design by Contract的指導之下, Design to interface幾乎變成其代名詞. 然而可以看到在利用接口實現(xiàn)問題的分解之后, 我們剩下的是什么? 將分解組合起來, 形成我們所需要的軟件! 可是這個時候問題來了, 怎么組合? 如果是你自己分解的零件還好, 如果不是呢? 分工可是大工業(yè)生產(chǎn)的必要條件.
組件之間如何通訊?Corba, DCom以及后來的RMI, Remoting, 這些解決方案都牢牢的定死了組件實現(xiàn)的平臺, 使得他們之間的交互成為枉然.
而組件自身無法提供足夠的描述信息, 更使得裝配式的生產(chǎn)成為遙不可極的夢想. 盡管在Java和.Net中都提供了一些metadata, 但是諸如方法,屬性如此少的描述信息又怎么能讓我們從如此多的對象中找到適合我們的需要的零件. 對象之間的依賴關系?誰主誰從? 對象如何通訊? 同步異步? 對象的信息如何修改? 直接間接? 如此多的信息, 目前的metadata遠遠無法提供.
記得小時候想玩一個鐘, 結(jié)果拆了之后卻再也裝不起來, 就丟在那了. 面向?qū)ο竽?/span>?...
通用
目前的開發(fā)方法與技術給了我們過多的自由, 使得我們可以在此基礎上開發(fā)出幾乎所有的應用. 但是當前大多的應用需要這樣的自由嗎? 看看下面的應用:
首先從數(shù)據(jù)庫讀取相應的數(shù)據(jù), 把數(shù)據(jù)以一定的業(yè)務規(guī)則展現(xiàn)給用戶, 而用戶在獲得數(shù)據(jù)的同時可以在一定的業(yè)務規(guī)則下修改這些的數(shù)據(jù),最后將修改后的結(jié)果寫入數(shù)據(jù)庫.
我不知道有多大比例的應用符合上面的模式. 相信各位心中會有自己的答案.
我們獲得了自由, 但是與之而來的也有復雜, 并且我們還失去面對變化的能力. C#和Java與C,C++相比,讓我們不用再理會復雜的內(nèi)存管理等等底層的技術問題, 讓我們更多的關注于所要解決的業(yè)務問題. 但是C#, Java是否也太通用了呢? 我們在擺脫了內(nèi)存管理后還是要關心對象的生命周期的管理, 對象的持久化, 對象的顯示等等技術問題, 他們并不是業(yè)務問題但是卻與業(yè)務邏輯糾纏在一起, 想想你編程的時候有多少時間是花在這些技術問題上的. 或許我們需要擺脫某些自由來獲得更多的方便.
看過勇敢的心的人無不被最后的”Freedom!”感動, 然而你能做到華萊士那樣嗎? 想想自己去喊 ”C” “Assemble” “01…”的樣子 模型 UML 看似成功的建模語言, 仔細想想它在軟件開發(fā)中的作用. 我個人平時喜歡寫一些有關設計的隨筆, 這時常常會用到UML. 如果你問我用它干什么, 我會說是為了形象化的說明我的意圖,我的代碼. 也就是說UML僅僅起到了文檔的作用. UML是可以描述對象模型, 但是僅僅是從文檔的角度而已, 程序員之間的交流手段. 它不是開發(fā)用的模型! 我們有用于開發(fā)的模型嗎? 你知道嗎?... 總結(jié) 有多少人(或公司)曾經(jīng)將完成的軟件做過好的總結(jié), 請舉手. 我個人目前還沒有一個讓我敢回首的軟件(當然個人經(jīng)歷太少,才學了4年而已,各位肯定有自己的得意之作). 不過我相信大家對這個問題的答案足以讓很多人臉紅. 其實這又何以責怪程序員, 目前的縱多開發(fā)方法中又有幾個提到了如何使用已有的軟件產(chǎn)品(組件, Pattern…), 以及開發(fā)后如何從產(chǎn)品中提煉出通用的產(chǎn)品(組件,Pattern,產(chǎn)品線…). 在以滿足需求為第一指導原則的軟件開發(fā)方法中哪里考慮過這些問題? 既然開發(fā)方法都沒考慮, 那么程序員又怎么會去考慮呢? 更何況,由于水平問題和我一樣不敢回首自己作品的程序員比比皆是. 再說了, 你會總結(jié)嗎? 怎么記錄Pattern? 誰知道好的方法? 在高中讀書的時候, 經(jīng)常會做總結(jié), 那時成績比較好, 現(xiàn)在上了大學, 好像真的很少做了, 難怪考試不行了. 待續(xù)…
參考資料: <<Software Factory>>
