: 推 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