: 推 rocairforce:我想，如果妳的程式是射後不理 那就別class了 09/06 11:00
: → LaPass:射後部裡的確用不著這種東西 09/06 11:26
: → yororu:我們公司接的案子都是一般的中小企業網站..要做的東西不是 09/06 17:30
: → yororu:很多..都單純是一般網頁客戶意見最新消息還有一些他們要求 09/06 17:31
: → yororu:的功能...我做過大概10幾20個網站..大部份都維護2~3年,也有 09/06 17:33
: → yororu:超過5年的..這些網站如果要去用frame做開發起來會很慢..我 09/06 17:34
: → yororu:一開始就是用class去寫..後來一直改..本來以為可以重覆使用 09/06 17:35
: → yororu:後來一改再改變得愈來愈寵大..我才放棄那種方法. 09/06 17:36
: → yororu:改成寫幾支每個網站可能會用到的function 放同一個php裡.當 09/06 17:37
: → yororu:要建新網站時直接copy過去..然後也是很快就建好.. 09/06 17:38
: → yororu:是否我寫的案子都不夠大所以不用使用mvc架構或class呢? 09/06 17:40
不需要為了 class 而 class，不需要為了 oo 而 oo，
所謂的 design pattern 原本就是為了處理問題而演化出來的解決方案，
而 design pattern 的模型往往需要物件導向特性來支撐，
所以如果根本沒有這些需求的時候，其實真的不要刻意為之，
那只會讓情況變無謂的複雜 XD
舉個例子，我現在在寫的專案頗有點複雜，
可以被瀏覽的角色有「個人」、「組織」、「單位」等等，
每種角色會有自己種類風格的首頁，有自己的權限管控，
我會把這些東西封裝成一個核心元件 (core component)，
每個登入進來的使用者封裝成使用者元件 (user component)，
而所有的行為和權限統統藉由這兩個物件模型之間的溝通來做掉，
如果今天有另外一個工程師接手做一個活動，它需要用到一個判定，
這個「被瀏覽的主角」，是不是「登入的使用者所擁有的」，
if ($user->own ($core))
就這樣（攤手
這個工程師不需要知道底層的啥鬼啥鬼，不需要知道資料表是如何設計，
如果要更進一步的權限，還可以這樣判定
if ($core->allow ($user, _DO_POST))
_DO_POST 是一開始就 deifne 好的常數
所以…嗯，我覺得真的是需求導向啦，
過度設計只會變成一個超大毛線團 = =
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 175.180.105.248