但是,术语的定义很可能是白费力气,因为一个定义可能对一个人(比如程序员)有意义,但是对另一个人(比如只能看到书面材料的项目主管)却毫无意义.当然,我不打算在这里提出什么最终定义.但是,任何对模式要素的规定,除了必须包括问题.解决方案与场景之外,都必须提及可重复性.可传授性与名称. 【程序编程相关:JAVA规则——开发篇】
确实,很难找到一个令人满意的定义.“模式讨论”邮件列表(patterns-discussion@cs.uiuc.edu)上正在进行的讨论也证明了这一点.难以定义的一大原因是:模式既是一个事物,也是对类似事物的描述.要区分这两者,有一种办法:“模式”这个术语只用来指代模式的描述,同时用“模式实例”来指代模式的具体应用. 【推荐阅读:Tutorial for buildin】
我通常把这些误解统称为“蔑视”.如果你试图把某些不熟悉的东西简化为熟悉的东西,产生这种想法是很自然的,尤其是当你没有特别的兴趣去钻研这些不熟悉的东西时.另外,某些人经常拿新瓶装陈酒,然后大吹“创新”.“革命”一类的口号.保持警惕也是好的. 【扩展信息:java 面试中的一道编写一个截取字符串】
误解之二:“模式就是行话.规则.编程技巧.数据结构……”
但是,这种蔑视通常不是来自亲身体验,而是来自肤浅的认识与一点点冷嘲热讽的.而且,没有什么东西是真正“全新”的.人们的脑海中一直都存在着各种各样的模式,只不过我们现在刚开始为模式命名.将模式记录下来.
来逐个说明这些看法:的确存在着模式的行话,例如“模式”这个词,例如“约束”,例如alexander的“无名质量”,等等.但是模式是不能简化为行话的.与其他计算机科学领域相比,模式引入的新术语实在是少得可怜.对于听众来说,好的模式本来就很容易接受.在说明一个模式的时候也许有必要引用问题领域的行话,但是几乎没有必要使用什么特定于模式领域的术语.
没有哪个模式是能让你不假思索就使用的规则(组件则正好相反),同时模式也不仅仅是“编程技巧”,尽管模式中的“方言(idiom)” 部分是特定于语言的.在我听来,“技巧”这个词带有轻蔑的意思,并且过分强调解决方案,而忽视了问题.场景与名称的重要性.
毫无疑问,你也曾经听说过一次创新被接受的三个阶段:首先,它被当作垃圾扔在一边;然后,人们会认为它不具可实施性;最后,大家都明白它的意义时,它也没有意义了——“我们一直都这样做”.现在,模式还没有完全走出第一个阶段.
误解之三:“理解一个,就理解了全部”
一刀切的规则往往是不公平的,而人们对模式却更加一刀切.... 下一页