Re: 物件导向的缺点 ??

楼主: tomtomtom456 (画画狐)   2008-10-10 00:37:56
※ 引述《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应用例子, 给大家参考.

Links booklink

Contact Us: admin [ a t ] ucptt.com