前文已经拉太长不好阅读，用回文的方式接续~~
: → 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淹死
研究作业模式，了解模型的哲学，才能应付这种问题