Re: 物件導向的缺點　？？

看板OOAD作者tomtomtom456 (畫畫狐)時間16年前 (2008/10/10 00:37)推噓5(5推 0噓 1→)

留言6則, 4人參與討論串12/13 (看更多)

※ 引述《legnaleurc (CA)》之銘言： : : 推 thinkniht :"過度疊床架屋"?什麼意思啊?看不懂=.=+ 07/14 18:47 : : 推 cplusplus :過度抽象化? 07/17 07:55 : : 推 H45 :疊床架屋，私以為是動態連結的意思。 07/17 09:17 : : 推 JustinHere :一層包一層，層層抽象化。。XD 07/20 22:41 : 就是過度抽象化的意思 : 以下舉一個很極端的例子: : 需求是寫一個九九乘法表我可以再舉一個例子像是一般常見的 Web 查詢程式丟個SQL到後端DB把資料撈出來, 顯示在螢幕上幾十行就可以寫完如果要物件導向的話也許要有個物件對應 Db Table 再來個物件處理SQL 如果你是會計資料的話, 可能要有個物件代表會計科目如果是庫存資料的話, 可能要有個物件代表庫存商品然後再套個MVC架構, Model 物件, 控制物件, 顯示物件需求都一樣啊, 顯示出來的畫面也都一樣啊但是這種OO設計的結果, 就會讓你多花不少的工時使用者/客戶/老闆才不會管你那麼多, 只會問你為什麼某某只花一天寫好, 你要花二天當然你可以想...哼哼, 我的程式俱備了OO的彈性, 不但好修改, 好替換, 而且還可以 Reuse 物件, 等到下次要寫其他類似的程式, 或是要修改時, 你們就知道了過了不久, 果然要修改了使用者要求要把欄位的字型變大, 呵呵, 只要改顯示物件就好了, 資料物件, Model.. 都不用修改再過幾天, 使用者要求要多一個欄位, 而且這個欄位要從另一個Table join 進來, 你忽然覺得有點不妙多個欄位, 那當然要改顯示物件啊; 那資料哪裡來, 從SQL來啊, 所以和SQL有關的物件也要改; 如果是MVC架構的話, Model和顯示都要改, 控制物件完全不用改嗎? 你之前設計的會計科目物件, 或是庫存商品物件, 若因此要增加一個或多個屬性或方法, 能不改嗎....不要忘了在這些物件之間呼叫與傳回的各種參數變數, 只要有一個地方對不起來, 你的程式就會有問題... 於是使用者/客戶/老闆又有意見了; 上次那個某某幫我們加欄位, 半天就好了, 你為什麼要弄那麼久 ? 呵呵...舉了一個很負面的OO應用例子, 給大家參考. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.224.35.146

Re: 物件導向的缺點 ？？

Re: 物件導向的缺點　？？