※ 引述《csfgsj (真理不滅)》之銘言：
: 前文已經拉太長不好閱讀，用回文的方式接續~~
: : → NodeWay: 知道一萬種DP果然是大師 在下才疏學淺只數得出二十來種 04/04 1
4:
: : 推 RunRun5566: 我理解的Design Pattern大概只有十幾種 04/04 1
5:
: : → Masakiad: DP並非用一種或數個架構要解決「所有」問題。DP是在特定 04/04 1
5:
: : → Masakiad: context（姑且稱環境）下產生的force(姑且稱問題），可 04/04 1
5:
: : → Masakiad: 以用同一種pattern去解決該force。但很多人忘記必須考慮 04/04 1
5:
: : → Masakiad: 該pattern產生相對應的force可能影響整體架構。但其實DP 04/04 1
5:
: : → Masakiad: 是有強調可能照成的相對force。另外pattern不指code或定 04/04 1
5:
: : → Masakiad: 型的class diagram，因為他意義上是指解決該force的一 04/04 1
5:
: : → Masakiad: 種固定手法，依我的能力這可能很難言語講明白。但patter 04/04 1
5:
: : → Masakiad: n包含由原概念產生的變形也算。所以pattern一直很少。 04/04 1
5:
: 從以上的敘述，我想我大概明白你的意思，也同意你的看法
: 因為你說出了一個重點：
: 「pattern不指code或定型的class diagram」
: 這跟OOSA、OOSD的論點比起來，清爽多了
: (做蛋糕為何一定要用大便做原料)
: 對你的看法，我的認知，其實可以用更傳統的詞彙來描述它
: Force =：特定環境下的特定作業(管理)需求。
: Ex：開一家餐廳，要如何營運
: Pattern =：為滿足這個需求，所採取的作業模式、系統模型等..
: Ex：餐廳的營運模式：客人進來，先看菜單、點餐、上菜、享用、結帳、離開
: 而同樣的作業模式，可能在若干其他不同的地方
: 雖然環境需求不見得完全相同，卻能似曾相似地被使用著
: Ex：K 房的營運模式：客人進來，大閱兵、點？、上？、享用、結帳、離開
: (跟餐廳的營運模式很像？)
: 因此類似這種，被很多不同地方同時套用的作業模式
: 就成了作業設計規畫者的一個，經典的問題解決方案
: 一個參考範例，一個模式罐頭
: 範例收集的越多，則能解決問題的辦法就越多
: 如您所述，當你收集了20種以上不同的模式罐頭
: 也就差不多能應付所有的管理作業問題了(大架構)
: 系統設計，也就只是在這些模式罐頭間，選擇合適的套用
: 大的系統，可能要同時套用許多不同的模式罐頭
: 之間的交錯又可能衍生出新的組合型模式罐頭來
: 反過來看，要分析一個現成的系統 (系統分析)，也就是在觀察
: 該系統用了哪些模式罐頭參考例內的模式
: 當該系統所有模式都清點解析完了，還不用涉入code的實作細節
: 對該系統的了解，就已經差不多達到七八成了
: 以上就是該系統的領域知識，這些都與程序語言無關
: 對於腦袋裡沒有什麼模式罐頭觀念的人
: 去看一個大系統的Code，只能說「只在此山中，雲深不知處」
: 迷路了不說，還很容易被大量的code淹死
: 研究作業模式，了解模型的哲學，才能應付這種問題
我是一位初窺大道的工程師 對於一些想法想和同輩交流
我認爲Design Pattern 寫到後面都是在解耦 並抽換物件
這東西像太極拳，當你忘記那些框框架架
善用基礎物件導向特性，當遇到事情複雜度和過份耦合上升
才要考慮是否要重複利用再考慮採注入或者抽象複寫方法
並理解不該把過分變動放到父類別等一些簡單設計原則
噁...說真的除非你對於系統的domain充分了解，
才能設計彈性和可擴充功能SOLID 不然都是邊做邊修
我看過太多硬要用模式而產生失敗的例子
建議初學者應該要加強語言特性和工具掌握度，並有基本OO概念
掌握Trace Code技巧，大概就踏出第一步
最後更上層進步法
怎樣板美容方法等等，轉接頭鴨子等等一些生活例子
接下來則是學習掌握本質和讓程式說話的技巧
好的程式是不用太多註解就會自己表達
軟體這條路真不管真理 歪理 只要能解決業務端問題
不會有人管你怎麼寫 除了工程師維護時會罵髒話
End