对模式的十大误解

模式引起大家强烈的兴趣的同时还伴随着一些迷惑、诧异和误解。这在一定程度上体现了主流软件开发人员认为这个领域有多么新，虽然从严格意义上说，它并不是一个新领域。这个领域的快速发展，也造成了一些空白。作为模式的倡导者，我们对此负有一定的责任：我们虽然一直努力让大家理解和接受模式，但是工作并不彻底。

为此，我感觉自己有义务来纠正那些对模式比较明显的误解，这些误解我常常耳闻，甚至可以自成模式了。我甚至还开玩笑地采用模式的形式来表述它们……直到那一刻我幡然醒悟：将任何事物都归纳为模式，这种行为本身就是对模式的一种误解！无论如何，请记住我并不是代表模式社区在发言。虽然我认为大多数模式专家都会同意这些是对模式最常见的误解，但就如何消除这些误解而言，他们的意见可能会与我的相左。

这些年人们对模式众说纷纭，令我反复思考，众多误解不过分为三类：一类有关模式是什么，一类有关模式能够做什么，还有一类有关一直以来在推动模式的社区。我所列举的“十大”误解都可以被归到这三类中。因此，我会将它们分门别类。首先来看看关于模式是什么的误解。

这是Christopher Alexander的定义，因此把它算作一种误解可能会显得有些离经叛道。但下面这个反例应该能够显露出它的不足。

问 题：

场 合：

解决方案：

虽然这是在一种场合下对一个问题的解决方案，但它并不是一个模式。那它缺少了什么呢？至少需要三样东西。

（1）再现（recurrence），这使得该解决方案不仅与当前场合下的问题有关，而且与当前场合之外的问题也有关。

（2）教学（teaching），这将教会我们去理解怎样对解决方案加以完善，从而适应问题的变体。（对实际使用的模式来说，与教学有关的大部分内容都包含在对问题的描述、对解决方案的描述以及应用模式后得到的结果中。）

（3）一个用来指代模式的名字。

诚然，一个令所有人都满意的定义是很难找到的，从“pattern-discussion”邮件列表（即patterns-discussion@cs.uiuc.edu）中持续的争论可略知一二。其中的困难在于，模式既是事物又是对相似事物的描述。区分两者的一种方法是，统一使用术语模式来表示描述，用模式实例来表示对模式的具体运用。

但是，定义术语可能只是徒劳无功，因为一个定义也许对一部分受众（如程序员）有用，但对另一部分受众（比如掌管公司财政大权的执行官）来说却毫无意义。当然，我也不会尝试在这里给出一个最终的定义。我只想说，任何一个规定模式的组成要素的定义，除了要讨论问题、解决方案和场合之外，还必须涉及再现、教学以及命名。

我称这种误解为“不以为然”。诚然，将不熟悉的事物归纳成已知的事物对我们来说是一件很自然的事情，尤其是在我们没有兴趣对不熟悉的事物进行深入研究的时候。再者，用新瓶装旧酒并号称创新的事情我们已经屡见不鲜了。保持警惕是应该的。

然而，“不以为然”并没有经验依据，很多时候它只是基于表面相似性的一种看法，还掺和些许轻视的态度。此外，从来没有什么东西是全新的，其实自从每个人出生起，各种模式就已经存在于他们的脑子里了。新的只是我们开始对模式进行命名并把它们记载下来。

来看看上面这句话。事实上的确存在一些模式行话，比如“模式”（pattern）本身、“推动力”（force）、Alexander的“无名的品质”（quality without a name），等等。但我们很难把模式简单归纳成行话。与计算机科学中的大多数领域相比，模式几乎没有引入什么新术语。事实上这是模式的特征，一个好的模式天生就很容易为它的受众所理解。虽然模式可能会用到它所面向的目标领域的行话，但我们几乎不需要为模式定义专门的术语。

模式不是可以盲目应用的规则（否则有悖于模式的教学特性）。模式也不仅仅是编程技巧，虽说“惯用法”关注的是与特定的编程语言有关的模式。“技巧”在我听起来有些贬义，它过分强调了解决方案，而忽略了问题、场合、教学以及命名。

毫无疑问，一项新事物要被接受会经历三个阶段：第一个阶段，它被当作垃圾，无人问津；然后它好像是不可行，无法推广；最后它变得显而易见，理所当然，人们会说：“我们一直以来都是这么做的。”模式目前还没有完全脱离第一阶段。

在过去的5年中，我曾经编写过模式，使用过模式，并帮助过别人使用模式，也参与设计过至少一个基于模式的工具。我可以很有把握地说，模式的优点来自于对模式本身的应用，也就是说不需要任何形式的支持。

当我在谈论这个话题的时候，我通常会指出模式的4个主要优点。

（1）它们提炼出专家的经验和智慧，为普通开发人员所用。

（2）它们的名字组成了一个词汇表，有助于开发人员更好地交流。

（3）系统的文档若记载了该系统所使用的模式，则有助于人们更快地理解系统。

（4）它们使得对系统进行改造变得更加容易，无论系统原来的设计是否采用了模式。

长久以来我原本认为大部分的优点来自第1点。现在我认识到第2点的重要性不亚于第1点。想一想：在软件开发的过程中，开发人员之间的口头及电子形式的交流的信息量有多少字节？我猜即使没有几吉字节，也有好几兆字节。交流如此多耗时自然多，任何有助于提高交流效率的东西都将为我们节省相当可观的时间。因此，模式使人与人之间的交流更顺畅高效。随着软件开发项目的规模变得越来越大，软件的寿命变得越来越长，我对第3点和第4点的重视程度也在不断提高。

简而言之，模式是供大脑消化吸收的食粮，而不是供工具加工的材料。方法论和自动化的支持对模式可能会有好处，但我相信这些都只是锦上添花的东西而已。

我们到目前为止讨论的误解都与模式是什么有关。现在让我们来讨论一些关于模式能做什么的误解。这些误解有两类：夸大其词类和轻描淡写类。

这个误解很容易批驳，因为模式并没有保证任何东西。它们甚至不能增加从中获取益处的可能性。模式并不能代替人来完成创造，它们只不过给那些缺乏经验但却具备才能和创造力的人带来了希望。

人们说到好的模式，会有恍然大悟之感。只有当模式能够触动心弦时，这种情况才会发生。如果模式无法触动心弦，那么它就像人迹罕至的森林中的一棵大树，纵使轰然倒下也没有人能听到它的声音。模式也是如此：即便它编写得再好，如果不能引起人们的共鸣，那么它好在哪里呢？

模式只不过是开发人员军火库中的另一件武器。将太多东西都归功于模式只能适得其反。要防止夸大其词的宣扬引发抵触情绪，最好的方法就是——少说多做。

这种误解与上一种误解很相似，只不过夸张的程度要轻一些。

在模式的论坛里，定期会有一些关于模式的产生能力（generativity）的讨论。我认为，产生能力指的是模式能够创造新行为（ermergent behavior）的能力。这种表述听起来很酷，其意思是模式能够帮助读者解决模式没有明确解决的一些问题。就我所知，还有一些观点认为，真正的产生能力几乎能够自动实现这一点。

对我来说，产生能力的关键在于模式与教学相关的部分，例如，对问题的描述和对解决方案的描述，或对效果的讨论。在定义和提炼架构的时候，这些见解尤其有用。但模式本身并不能产生任何东西，能够产生东西的是人，只有当人具备足够的经验并且他们使用的模式足够好的时候，他们才能够这样做。而且，模式不可能涵盖架构的方方面面。给我看一个稍有规模的设计，我一定能发现既有模式尚未涉及的许多设计问题。也许这些问题不常见或不经常发生，或者只不过它们尚未被编写成模式的形式。但无论如何，我们需要运用自己的创造力来填补各种现有模式之间的空白地带。

误解的另一个极端是过分贬低模式的作用，就像现在讨论的这一种。竟然有人会相信这种说法，坦白地说，我对此感到很惊讶。然而有许多人曾经就这个问题问过我，多到足以让它能够在十大误解中占有一席之地。如果你觉得这种误解太过幼稚，那么可以直接跳到下一种误解。

如果模式不能把专家的经验记录下来，那么它们就一无是处。究竟记录哪些经验则由模式的编写者决定。在面向对象的软件设计中，当然有值得记录的经验，但在非面向对象的设计中，同样有值得记录的经验。不仅在设计领域有值得记录的经验，而且在分析、维护、测试、文档、组织结构等领域都有值得记录的经验。这些不同领域中的模式正在浮现。目前在分析模式领域，已经至少出版了两本书，而且每一届的PLoP会议都会吸引一些新型的模式。（提交给1996年会议的一个模式特别有意思，它是关于音乐作曲的模式！）

与大多数的误解一样，这种误解也有一定的道理。如果看一看人们使用模式的形式，就会发现两种基本的风格：一种是《设计模式》一书所使用的高度结构化的GoF风格，另一种是Christopher Alexander的近乎纯文学的风格——叙述的文体，采用尽可能少的结构。在我涉足为面向对象设计以外的领域编写模式之后，才认识到GoF风格是多么地偏向面向对象领域。在我尝试过的其他领域，GoF风格根本不适用。对C++惯用法来说，它的结构图应该是什么样的？对音乐作曲的模式来说，它在实现上的取舍应该是什么样？对于用来撰写好的说明文的模式来说，它的协作部分应该是什么样？

显然，没有任何一种模式能够适用于所有领域。唯一能够适用于任何领域的是一个通用的概念——无论在什么领域，模式都是一种用来记录和传播专家经验的工具。

这种误解在过去还能站得住脚，但现在已经不是那么回事了。人们正在通过各种渠道报道模式所带来的好处，这些渠道包括Software—Practice and Experience之类的期刊，以及OOPSLA [HJE95, Schmid95]和ICSE [BCC+]之类的会议。Doug Schmidt也曾经表示过，模式对大学生和研究生的计算机科学教学有诸多好处[PD96]。虽然这些大多是定性的分析，但就我所知，至少有一个团体正在进行受控的实验，以获取量化的结果。

随着时间的推移，我们会更加清楚使用模式所带来的好处和隐患。即使最初的反馈非常好，我们仍然需要积累更多的经验，这样才能得到一个更加全面的评估。但是，如果仅仅因为模式所带来的好处还没有被完全量化就拒绝马上开始使用模式，那绝对是很愚蠢的行为。

关于模式能够做什么的谬论就到此为止。下面最后两种误解与模式本身无关，而与拥护模式的社区有关。

模式社区里常常有著作发表，但社区中有学术背景的人相对来说却并不多，对此有人可能会感到不解。事实上，PLoP的大多数与会者都是软件行业的从业人员，而且似乎一直以来都是这样。软件模式的早期拥护者们（包括Kent Beck、Peter Coad以及Ward Cunningham）没有一个是来自学术界的。GoF中只有一个（Ralph）来自学术界，而且他是我所见过的最讲究实用性的学者。模式社区的草根本质显然与那些所谓的同种论（homogeneity）和精英论是背道而驰的。

我曾经不止一次听到对模式的责难，说模式的主要用途是作为那些编著模式方面图书的人的收入来源。甚至还有一种说法是模式正朝着一个不可告人的方向发展。

完全是一派胡言！

作为GoF中的一员，我可以非常肯定地说，我们4人和其他任何人一样，对于人们对《设计模式》的反响感到惊讶。毫无疑问，当设计模式在1994年的OOPSLA会议上初次亮相时，我们4人对它所引起的轰动效应完全没有心理准备，读者的大量需求甚至让出版社都感到措手不及。在写书的整个过程中，我们最多的考虑就是尽我们所能来创造一本最高质量的图书。为了深入理解模式的内容，我们已经太忙了，根本无暇考虑销售问题。

当时的情况就是那样。现在模式 已经成为了一个重要的术语，因此有些人想利用它来谋取一些私利也在所难免。但是，如果仔细地阅读那些模式领军人物编写的作品，你就会感受到其***同的宗旨：将来之不易的专家经验、最佳实践，甚至是竞争优势——多年亲身实践所积累的经验硕果——不仅展露出来而且传授给所有后来者。

正是这种要提升所有读者的软件设计能力的热情，激励着每一位真诚而富有成效的模式编写者。缺少任何一项因素，那只能是适得其反，并最终导致对模式的误解。

澄清了这些误解之后，人们对设计模式的反应不外乎有两种。下面我会通过一个类比来对它们进行描述。

设想有一个电子爱好者，虽然他没有经过正规的培训，但是却日积月累地设计并制造出了许多有用的电子设备：业余无线电、盖革计数器、报警器等。有一天这个爱好者决定重新回到学校去攻读电子学学位，来让自己的才能得到正式的认可。随着课程的展开，这个爱好者突然发现课程内容都似曾相识。似曾相识的不是术语或表述的方式，而是背后的概念。这个爱好者不断学到一些名称和原理，虽然这些名称和原理原来他并不知道，但事实上他多年以来一直都在使用。整个过程只不过是一个接一个的顿悟。

现在让我们把镜头切换到一个大学新生，这个新生正在同一个班学习同样的课程。他没有电子学的背景，有的只是大量的轮滑经验，没错，但就是没有电子学的背景。对他而言，学习新课程极其吃力，这并不是因为他笨，而是因为这些内容对他来说完全是新的。这个新生需要花更多的时间来理解和领会所有的内容。通过努力学习再加上一点毅力，他最终完成了所有的课程。

如果你觉得自己像一个设计模式爱好者，那么你会更加有动力。如果你觉得自己更像一个新生，那么请振作起来：你在学习好的模式上的付出是不会白费的，只要将它们应用到自己的设计中就会得到回报。我保证。

但对有些人来说，电子学这个类比可能不太贴切，因为其中包含了“电子技师”的内涵。如果你也这样认为的话，那么不妨考虑一下Alfred North Whitehead在1943年说过的一句话，虽然是在不同的场合下说的，但它也许会更加贴切：

艺术就是将一种模式强加于经历，以及识别这种模式时所带来的审美享受。

本文节选自《设计模式沉思录》

内容简介

本书在GoF的《设计模式》一书的基础上进行了拓展，运用其中的概念，介绍了一些技巧，帮助读者决定在不同的情况下应该使用哪些模式，以及不应该使用哪些模式。本书不仅对已有的一些模式提出新的见解，还让读者见证开发新模式的整个过程。

本书适合使用设计模式的软件开发人员阅读。

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF91EA600001E0321B801A9039A0

软件开发 软件开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。