前文已經拉太長不好閱讀，用回文的方式接續~~
: → NodeWay: 知道一萬種DP果然是大師 在下才疏學淺只數得出二十來種 04/04 14:57
: 推 RunRun5566: 我理解的Design Pattern大概只有十幾種 04/04 15:00
: → Masakiad: DP並非用一種或數個架構要解決「所有」問題。DP是在特定 04/04 15:25
: → Masakiad: context（姑且稱環境）下產生的force(姑且稱問題），可 04/04 15:25
: → Masakiad: 以用同一種pattern去解決該force。但很多人忘記必須考慮 04/04 15:25
: → Masakiad: 該pattern產生相對應的force可能影響整體架構。但其實DP 04/04 15:25
: → Masakiad: 是有強調可能照成的相對force。另外pattern不指code或定 04/04 15:25
: → Masakiad: 型的class diagram，因為他意義上是指解決該force的一 04/04 15:25
: → Masakiad: 種固定手法，依我的能力這可能很難言語講明白。但patter 04/04 15:25
: → Masakiad: n包含由原概念產生的變形也算。所以pattern一直很少。 04/04 15:25
從以上的敘述，我想我大概明白你的意思，也同意你的看法
因為你說出了一個重點：
「pattern不指code或定型的class diagram」
這跟OOSA、OOSD的論點比起來，清爽多了
(做蛋糕為何一定要用大便做原料)
對你的看法，我的認知，其實可以用更傳統的詞彙來描述它
Force =：特定環境下的特定作業(管理)需求。
Ex：開一家餐廳，要如何營運
Pattern =：為滿足這個需求，所採取的作業模式、系統模型等..
Ex：餐廳的營運模式：客人進來，先看菜單、點餐、上菜、享用、結帳、離開
而同樣的作業模式，可能在若干其他不同的地方
雖然環境需求不見得完全相同，卻能似曾相似地被使用著
Ex：K 房的營運模式：客人進來，大閱兵、點？、上？、享用、結帳、離開
(跟餐廳的營運模式很像？)
因此類似這種，被很多不同地方同時套用的作業模式
就成了作業設計規畫者的一個，經典的問題解決方案
一個參考範例，一個模式罐頭
範例收集的越多，則能解決問題的辦法就越多
如您所述，當你收集了20種以上不同的模式罐頭
也就差不多能應付所有的管理作業問題了(大架構)
系統設計，也就只是在這些模式罐頭間，選擇合適的套用
大的系統，可能要同時套用許多不同的模式罐頭
之間的交錯又可能衍生出新的組合型模式罐頭來
反過來看，要分析一個現成的系統 (系統分析)，也就是在觀察
該系統用了哪些模式罐頭參考例內的模式
當該系統所有模式都清點解析完了，還不用涉入code的實作細節
對該系統的了解，就已經差不多達到七八成了
以上就是該系統的領域知識，這些都與程序語言無關
對於腦袋裡沒有什麼模式罐頭觀念的人
去看一個大系統的Code，只能說「只在此山中，雲深不知處」
迷路了不說，還很容易被大量的code淹死
研究作業模式，了解模型的哲學，才能應付這種問題

他講的design pattern不是你說的那種東西