何必非要OOP？

lgx522發表於2007-02-12
OOP
這篇文章其實是筆者多年以來的疑問感悟所成，估計各位居於不同語言陣營中的同道們也會有不少類似的疑問，願此文拋磚引玉，與大家共同探討OOP與程式式程式設計的是是非非。

筆者轉向Java Web程式設計前從事的是傳統的Delphi C/S程式設計。轉過來後就覺得J2EE分層太多，每到更改，每層幾乎都要涉及，相當麻煩且易出錯。在Java Web之餘，又涉及了一些ASP、PHP之類的東西，才發覺Web程式設計也可如此簡單，不禁對J2EE產生了很大的疑問：本來可以簡單實現的東西，何必搞得那麼複雜？
近兩年OO水平上漲後才逐漸領會到其中玄機。OO與分層最重要的好處其實業務邏輯及類庫的複用！OOP將資料儲存、業務邏輯、表示層分離，就可以適應多種資料儲存方式與表示層技術的變化。比方說，你就可以選用多種資料庫、XML甚至文字！也可以選擇WEB、Rich Client以至於手機、PDA。當儲存層與表示層變化時，業務層幾乎可以保持不變。原因其實也簡單：傳統的程式式程式設計是把他們在一塊寫，而OO則是分開來寫。而天下事總是利弊相當，OOP的高適應性也就必然為其帶來高度的複雜與費時，甚至修改時的麻煩。綜上所述，OOP其實是便於擴充套件而不適於修改。原因簡單之極，寫在一起的改起來只需改一處，分開寫的改起來則要改每一處。
這一點上順便提一下Sun的經典J2EE。經典J2EE其實是把OOP做到了極致，除卻上述堅決的三層分離外，EJB更把資料儲存層的事務與業務層的分散式特性加入其中。這對大型系統而言絕對是極大的福音。而中小型系統基本上是不需要事務與分散式的，這樣一搞就讓J2EE非常複雜。於是Sun的經典J2EE遭到了絕大多數中小系統應用開發者一致的口誅筆伐。可到了真正的企業級領域，J2EE的地位卻難以撼動。這充分說明了OOP的極致是適應性與複雜性的綜合體。這好比生物界中的生物，適應性越高的生物（如人類）必然越複雜。

是否採用OOP，OOP用到什麼程度，要因軟體產品的定位而論。如果考慮的是擴充套件性，業務邏輯相對固定，而儲存層、表示層變化多的情況下，OOP當是不二之選；而儲存層、表示層相對固定，業務邏輯變化大的情況下，則應選用程式式程式設計。如果二者變化程度均衡，則可採用MS騎牆式的方法。筆者這番大膽言論其實並非由理論推導而來，而緣於對當今軟體界的實際觀察。真正的企業級開發無疑J2EE是主導，這符合第一種情況；而變化迅速的網際網路界則以PHP為王，小型桌面系統至今仍以VB、PB、Delphi為佳，這符合第二種情況；而中型系統，.NET發展得最好，這正是第三種情況。
所以我們搞軟體的諸位同道，居於不同的陣營中，不免終日比短較長，其實是沒有必要的。各種語言都有他的優勢與適用範圍。做好產品、服務的市場定位與技術定位，揚長避短才是明智之舉。

相關文章