Re: [分享] 面向對象編程從骨子裡就有問題
說到OOP精神的極致化,就不得不得提一下EJB這個龐大框架了了...
在J2EE的領域裡，EJB一直被視為重量級的應用，
似乎一個專案如果用了EJB身價就立刻變得不一樣，技術人員也以學會EJB為傲，
不管這樣的觀念是否正確，.....
http://my.so-net.net.tw/idealist/EJB/index.html
不過實際上是 http://zh.wikipedia.org/wiki/EJB
，起初一些大公司紛紛採用EJB部署他們的系統。然而隨後各種問題便接踵而至，
對EJB的惡評短時間內激增。對於初學者，EJB的API顯得太過困難；
對於許多程式設計師來說，
書寫那些必須丟擲特定異常的介面並將bean類作為抽象類實作的做法既不直觀也不正常。
當然，EJB所被賦予的使命，如物件關聯對映和事務管理確實有其天然複雜性，
但其API之複雜還是令開發人員們覺得望而卻步，
一些人開始懷疑EJB除了引入了複雜的實作手段以外似乎並未帶來什麼實際好處。
另外，實際運用中被發現，如果使用EJB來封裝業務邏輯會帶來效能上的下降。
ejb在3.0後化繁為簡,我的短暫開發經驗是直接用3.0版本後,
不過還是覺得很囉嗦,特別是環境配置之類的問題,之後任務調動,
後面就不關我的事了
(方法等等都不是我決定的,我只是莫名其妙被拉過去支援一下)
結果就是使用ejb和jpa加上層層複雜的架構設計之下,用大砲打小鳥,
加上不是那麼純熟的設計技巧,以及沒有分散的硬體來支撐處理效能,
結果效能出問題.....現在好像是把問題推就到JPA框架上,大概認為是query效能問題,
所以準備改用nosql.(不過我強烈懷疑問題是出在哪裡的memory leak上,
至少就我當時的測試,一段時間後回應時間就慢下來,反正我不是那TEAM的人).
其實跟著技術上所謂的政治正確走,沒有考慮到環境條件.目地的適用性,
嘴巴上滿口引領潮流的新技術,通常就算成功,結果也頂多是普普通通.....
OOP大概也是這麼回事,專案有大有小,規模差異不少,
如果考慮到大型專案多人分工的狀況,基於維護性的考量(不是效能喔...),
良好的層層架構包裝是需要的,那中小型專案呢? 中型可能有爭議,
先不談,一個人可以ko的小型專案,還把一些簡單到不行功能一層一層包上去,
考慮良好oo精神.未來擴充的可能性,明明簡單可以ko掉的東西,
為了保有oo的精神理念,程式碼量多了好幾倍,為了就是對oop嚴謹的"態度",
你信嗎? 很多人信,我是不信拉...
東西沒bug,早點丟出去,早點回家比較實際,我是這樣覺得.
所以一些技術文章對OOP的批評,我覺得就是類似的原因,
如果實際上沒好處也沒必要,堅持道地純正的OOP精神所求為何?
當你這樣說時,最有可能是被某些人說"我不認為你懂OO!",
算了不懂也沒差,歡喜就好.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.248.56.181
推
02/23 10:51, , 1F
02/23 10:51, 1F
→
02/23 10:52, , 2F
02/23 10:52, 2F
→
02/23 10:53, , 3F
02/23 10:53, 3F
→
02/23 10:55, , 4F
02/23 10:55, 4F
→
02/23 10:55, , 5F
02/23 10:55, 5F
→
02/23 10:56, , 6F
02/23 10:56, 6F
→
02/23 10:58, , 7F
02/23 10:58, 7F
→
02/23 10:59, , 8F
02/23 10:59, 8F
→
02/23 13:57, , 9F
02/23 13:57, 9F
推
02/23 14:24, , 10F
02/23 14:24, 10F
→
02/23 14:25, , 11F
02/23 14:25, 11F
推
02/25 20:06, , 12F
02/25 20:06, 12F
討論串 (同標題文章)
完整討論串 (本文為第 6 之 12 篇)：
分享
14
46