※ 引述《prag222 (prag)》之铭言：
DP 没有这么重要
能运作、好维护、好扩充、好调整 就是好设计
不应该"过度"把精力放在DP
有时只是"规模很小"的东西 某些组件用的次数也不多
你却用了很精良的设计
- 浪费实作工时
- 降低修改与调整性 (受限于设计)
- 降低维护性 (不是每人都"精通"你的模式，维护后模式总是会分裂、突变)
结果，也许最"阳春"、最像新人写的那种，说不定才是最好的。
写code技术的演进流程:
1. Script code
2. 物件化
3. 模式化
4. 反朴归真化 (有"需要"物件化才抽、有"需要"到模式化的规模才设计)
不过，在台湾
你还是全部都模式化保护自己吧，这是斗code 时常用的工具阿。
很多专案就在这种斗CODE风气之下，逐渐突变
- 恶斗造成团队"过度"追求物件化、模式化、命名，这些无实际价值的东西
而非把精力放在使用者，或着实际问题的解决与优化上
突变到无法收拾后，专案肥大到无法即刻随使用者需要调整，
连调整简单的"UI"，都有极高的维护阀值。
苦的是大部分人，笑的，是制造斗争，以假象哄抬自己身价的人。
说到底，还是终归一句，这些都不重要。
工程师是做事的、还是生事的比较重要
: ※ 引述《Wolfken ()》之铭言：
: : Design Pattern不一定要用,但一定要会
: : 那本书里面的pattern是一回事,里面另一个重点是设计的概念
: : 它书主要是这样,说明什么设计会产生什么问题,然后可以用什么pattern解
: : 前面那个跟后面那个一样重要呀,没看过书你遇到烂架构还不会知道这是烂架构
: : 像是favor object composition over class inheritance
: : 信不信一大票号称十年以上经验的资深工程师
: : 写出来的code还是一堆继承然后很少interface跟composition
: : 然后跟你说我觉得很好呀,哪边有问题?
: : 首先你得要有看出现在架构有没有问题的能力,再来谈要用什么解决方案
: : 要不要用pattern,还是自己想的解法,甚至基于YAGNI原则暂时先摆着
: : 那是找出问题之后的事了
: : 简单的架构问题,不用看书,大部份有几年经验的工程师都看得出来
: : 书中会写的大部份都是就算十年以上经验
: : 没认真想过架构或是实际体验过烂架构带来的痛苦
: : 一辈子也不会找得出来的问题
: : 作者累积多年功力跟许多专案中烂架构的经验,才能写出这本书
: : 所以重点就是吸收他的经验,让自己找出烂架构的功力提升
: 首先感谢大大的回复!
: 其实小弟是写网页出身的
: 工作经验是从ASP网页(维护)开始兼后端开发
: 小弟看一看Design Pattern也觉得是必学的
: 第一次看到用compoistion来解决设计上的问题,才发现进到了新天地
: 因为以往过去工作都找网页程式设计
: 直到最近工作才觉得好像有点不太会写程式
: 看了DP才觉得 程序程式导向跟物件导向程式设计的不同
: 坦白说这也是工作经验跟学习领域不同的关系
: 看一看DP才觉得DP是学习OO Design重要的垫脚石
: 从另一个学习面来看DP怎么用物件导向技巧实作解决问题
: 小小心得.....尚在学习,感恩....XD