※ 引述《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
这只是对DP 不懂的人的说词,君不见本版动不动就DP一下就知,只要有DP, 随便都有好程式.
作者:
robler (章鱼丸)
2016-04-04 23:26:00程式是用写的 不是用讲的 太多讲的一嘴好程式的人了
作者:
tyc5116 (累人啊....)
2016-04-05 00:10:00"只要有DP,随便都有好程式",1F确定?
作者:
Argos (Big doge is watching u)
2016-04-05 01:02:00注解喔 我还是觉得一定要至少写上大纲... 就算名字取得再好你永远也无法保证下一个看你程式的工程师英文程度如何...XD
楼上注解是用中文写？我个人对DP的见解是，当你觉得遇见相同模式的问题能很快且自然的联想到解决方法，而不用在那边想半天该用什么方式去处理，这就是学习DP优点。别走火入魔的话，多学习一定是有益无害的。
作者:
csfgsj (切割对半)
2016-04-05 07:29:00不要忘了，OO的框架，可都是一种硬框架，用起来问题一堆
作者:
Argos (Big doge is watching u)
2016-04-05 19:56:00用中文写有什么奇怪的？公司里没有外国工程师阿
作者:
Masakiad (Masaki)
2016-04-06 17:07:00美丽的东西总是充满陷阱