※ 引述《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