前文已经拉太长不好阅读，用回文的方式接续~~ : → 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