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