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