这个模式是什么意思?
发布网友
发布时间：2022-04-28 18:09
共2个回答
热心网友
时间：2022-06-22 18:56
"模式就是在一种场合下对某个问题的一个解决方案。"
这是Christopher Alexander的定义，因此把它算作一种误解可能会显得有些离经叛道。但下面这个反例应该能够显露出它的不足。
问题：如何在过期之前兑现中的彩票？
场合：离最后期限只有一小时，一条狗把彩票吃了。
解决方案：剖开狗的肚子，取出彩票，然后飞奔到最近的兑现点。
虽然这是在一种场合下对一个问题的解决方案，但它并不是一个模式。那它缺少了什么呢？至少需要三样东西。
(1) 再现（recurrence），这使得该解决方案不仅与当前场合下的问题有关，而且与当前场合之外的问题也有关。
(2) 教学（teaching），这将教会我们去理解怎样对解决方案加以完善，从而适应问题的变体。（对实际使用的模式来说，与教学有关的大部分内容都包含在对问题的描述、对解决方案的描述以及应用模式后得到的结果中。）
(3) 一个用来指代模式的名字。
诚然，一个令所有人都满意的定义是很难找到的，从"pattern-discussion"邮件列表（即patterns-discussion@cs.uiuc.e ）中持续的争论可略知一二。其中的困难在于，模式既是事物又是对相似事物的描述。区分两者的一种方法是，统一使用术语模式来表示描述，用模式实例来表示对模式的具体运用。
但是，定义术语可能只是徒劳无功，因为一个定义也许对一部分受众（比如程序员）有用，但对另一部分受众（比如掌管公司财政大权的执行官）来说却毫无意义。当然，我也不会尝试在这里给出一个最终的定义。我只想说，任何一个规定模式的组成要素的定义，除了要讨论问题、解决方案和场合之外，还必须涉及再现、教学以及命名。
误解2
"模式只是行话、规则、编程技巧、数据结构……"
我称这种误解为"不以为然"。诚然，将不熟悉的事物归纳成已知的事物对我们来说是一件很自然的事情，尤其是在我们没有兴趣对不熟悉的事物进行深入研究的时候。再者，用新瓶装旧酒并号称创新的事情我们已经屡见不鲜了。保持警惕是应该的。
然而，"不以为然"并没有经验依据，很多时候它只是基于表面相似性的一种看法，还掺和些许轻视的态度。此外，从来没有什么东西是全新的，其实自从每个人出生起，各种模式就已经存在于他们的脑子里了。新的只是我们开始对模式进行命名并把它们记载下来。
来看看上面这句话。事实上的确存在一些模式行话，比如"模式"（pattern）本身、"推动力"（force）、Alexander的"无名的品质"（quality without a name），等等。但我们很难把模式简单归纳成行话。与计算机科学中的大多数领域相比，模式几乎没有引入什么新术语。事实上这是模式的特征，一个好的模式天生就很容易为它的受众所理解。虽然模式可能会用到它所面向的目标领域的行话，但我们几乎不需要为模式定义专门的术语。
模式不是可以盲目应用的规则（否则有悖于模式的教学特性）。模式也不仅仅是编程技巧，虽说"惯用法"关注的是与特定的编程语言有关的模式。"技巧"在我听起来有些贬义，它过分强调了解决方案，而忽略了问题、场合、教学以及命名。
毫无疑问，一项新事物要被接受会经历三个阶段：第一个阶段，它被当作垃圾，无人问津；然后它好像是不可行，无法推广；最后它变得显而易见，理所当然，人们会说："我们一直以来都是这么做的。"模式目前还没有完全脱离第一阶段。
误解3
"看到了冰山的一角，就等于看到了冰山的全部。"
以偏盖全不是一种正当的做法，如果用这种方式来看待模式，那就大错特错了。模式所涉及的领域、内容、范畴和风格非常广泛，而且它们的质量也千差万别。只要随便翻阅Pattern Languages of Program Design 丛书中的一本，就可以感受到这一点。模式和编写模式的人一样多样，也许有过之而无不及。随便举几个例子，Alistair Cockburn、Jim Coplien、Neil Harrison以及Ralph Johnson等，虽然这些作者一开始也曾尝试用多种风格来为不同领域编写模式，但是现在他们早已经超越了这个阶段。因此，仅仅通过少数几个例子就对模式下一个笼统的结论是错误的。
误解4
"模式需要工具或方法的支持才能生效。"
在过去的5年中，我曾经编写过模式，使用过模式，并帮助过别人使用模式，也参与设计过至少一个基于模式的工具。我可以很有把握地说，模式的优点来自于对模式本身的应用，也就是说不需要任何形式的支持。
当我在谈论这个话题的时候，我通常会指出模式的4个主要优点。
(1) 它们提炼出专家的经验和智慧，为普通开发人员所用。
(2) 它们的名字组成了一个词汇表，有助于开发人员更好地交流。
(3) 系统的文档若记载了该系统所使用的模式，则有助于人们更快地理解系统。
(4) 它们使得对系统进行改造变得更加容易，无论系统原来的设计是否采用了模式。
长久以来我原本认为大部分的优点来自第1点。现在我认识到第2点的重要性不亚于第1点。想一想：在软件开发的过程中，开发人员之间的口头及电子形式的交流的信息量有多少字节？我猜即使没有几吉字节，也有好几兆字节。（在我们编写《设计模式》一书的过程中，我保存下来的我们4人之间来往的电子邮件文件大小达数兆字节之多。我认为我们所付出的精力，差不多相当于开发一个小型到中等规模的软件项目。）交流如此多耗时自然多，任何有助于提高交流效率的东西都将为我们节省相当可观的时间。因此，模式使人与人之间的交流更顺畅高效。随着软件开发项目的规模变得越来越大，软件的寿命变得越来越长，我对第3点和第4点的重视程度也在不断提高。
热心网友
时间：2022-06-22 18:56
