前文已經拉太長不好閱讀，用回文的方式接續~~ : → 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淹死 研究作業模式，了解模型的哲學，才能應付這種問題 -- [新聞] 「多個願望一次滿足」混合包 喝了恐暴斃 -- 打錯不是DP，是DK 已修正 我第一時間就說DP是設計方法論，被說不是這個東西 後來我想說，那DP是系統模式摟！現在又被說不是系統模式 那你來說說DP是什麼吧！ 這是不是有人將「處理問題、尋找答案的方法論、步驟」與「問題答案形式的列舉分析」 兩者混在一起了呢？ ※ 編輯: csfgsj (36.229.211.178), 04/04/2016 21:22:48