※ 引述《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