模式讨论FAQ

 

Doug Lea著,Qian_x_j

 

Doug Lea 维护。有什么意见、评论请发邮件: mailto:dl@cs.oswego.edu 最后更新于 2000.11。

 

这不是通常所理解的FAQ(常见问题解答)。本文的话题提炼并精简于模式讨论列表,格式为问答方式。条目列表内容的取舍只是反映维护者的个人观点。这些FAQ会不定期的更新。

 

有关模式(patterns)的更多信息,包括:在线模式的链接,模式的论文,有关模式行为的书籍描述,讨论会议的日程,有关模式的邮件列表,请参见The Patterns Home Pagehttp://www.hillside.net/patterns)。

 

1、“模式”这个术语为什么没有一个很好的定义?

为什么大部分工程术语没有一个很好的定义?“模式”一词跟“对象”一样,看上去至少还过得去。似乎没有人介意使用这个短语,“在某一个情景下的问题解决方案”,。然而,这个短语会产生混淆。解释这些术语,对你会有所帮助:

l         场景(context)是指模式应用其中,并可重复出现的一些情形。

l         问题(problem)是指一套发生在场景中的约束(forces) -- 目标(goal)和限制(constraints)。

l         解决方案(solution)是指一种规范设计范式或者设计规则。人们可以用来解决这些约束(forces)。

有关更加广泛的模式定义的讨论,可以参见:

The Patterns Home Page(http://www.hillside.net/patterns)和

WikiWikiWeb(http://c2.com/cgi/wiki?WelcomeVisitors)。

 

2、难道不能用一个比“模式”更好的词来描述这些事物吗?

你可以用任何自己喜欢的词来称呼他们,但是现在要改变这个叫法已经太晚了,多数人已经这样叫了。

 

3、设计模式(design pattern)跟模式(pattern)有何不同?

    模式的概念非常广泛,它能够适用于各种场景。

    “四人帮”(Gang of Four -- Gamma, Helm, Johnson, and Vlissides)所著的《设计模式》一书几乎完全专注于处理微观结构(micro-architecture)(也被称为对象结构(object structures))的模式。这些结构是在面向对象的开发中形成的一些静态和动态对象(和/或它们的类)之间的关系。术语“设计模式”开始涉及这一类模式。它们已经成为了模式著作中最常见的模式了。

 

有人错误的把术语设计模式”用到任意的对象结构上,甚至是那种在任何意义上都不能成为模式的东西。请不要这样做。

 

4、模式还可以在什么地方得到应用?

与软件相关的现有例子包括:

程序设计习惯用法(idiom)

例如,C++中的嵌套类的特殊应用,Java中的接口,Smalltalk中的层叠调用(cascaded calls),…。

编码习惯用法(idiom)

例如在C中的习惯用法:while (*dest++ = *src++)。

数据结构

例如树(trees)和缓存(buffers)。

算法

例如,那些关于并行处理(parallel processing)的模式。

协议

例如,那些并发对象(concurrent object)系统的应用模式。

新框架的开发(一系列扩展类)

例如,那些关于用户界面(UI)工具包的模式。

现有框架的应用

例如,OpenDoc, JavaBeans,…。

分析模型

例如,那些用会计学规则处理的模式。

系统结构

例如,黑板和代理结构。

开发组织

例如,开发团队的组织与发展。

开发过程

例如,面向对象分析设计的步骤和策略。

 

另外,模式已经被应用到了软件开发以外的一些领域。

 

5、模式和编码习惯方法(coding idiom)有何不同?一个设计?一个或者多个OMT 或UML图?一个用例(use case)?一个协议?一种算法?一种试探法(heuristic)?一个结构?一种编码规则?一种编码风格?一种开发方法?

一个模式可能围绕着上述中的某一项 ,但是单独的一项不能构成一个模式。一个模式描述了在一个假定的开发场景中这些项是如何被应用,以及为什么被应用,并提供应用它们的指导。

 

6、模式和类有何不同?是一个可重用的组件?一个参数表示的(模板)类?一个类库或者包?一个框架?一个工具?一个代码产生器?

一个模式并非是一个实现(implementation)。它描述了:什么时候、为什么、并且怎样,去创建一个实现或者其它工程产品。

 

有一些(并非很多)解决方案有必要通过“实现”来描述(比如类、框架、工具、或者其它什么的)。实现可以告诉开发者,他们将需要知道或者需要做的全部东西。即便如此,代码本身并非模式。

 

7、模式跟类似于“如何做”这种向导有何区别?

模式中描述的解决方案可以是由一些精简的短句表示的步骤,这些步骤就像那些“如何做”向导和烹饪的菜谱中的步骤。但是这些步骤只是形成了模式的一方面。并且,模式追求更广的适用范围和场景的普遍性,同时在明确和解决约束问题上比那种典型的“如何做”向导更具权威性。

 

8、模式的研究跟专有领域的软件体系结构、软件复用以及其它领域的软件工程有何区别?

看来有一些重叠。

 

9、我在哪能找到有关XXX方面模式的出版物或者在线资料?

    没有一个为模式而设立的集大成之地,但是查找这些资料并不是很难。

下面是一些启蒙点:

l         Hillside Patterns Home Page

l         Linda Rising的书 《模式年鉴》(The Pattern Almanac) (也是模式的前辈,模式手册),囊括了大部分已发表模式的参考;

l         Wiki

l         Pattern Depot

l         Open directory

l         还有你喜欢用的搜索引擎。

 

10、克里士多夫.亚历山大(Christopher Alexander)是谁?

亚历山大是一个建筑师(是建造业的,并非软件业),他发明了模式。有关他的简单传记以及其相关文章、网页的链接可以在此处找到:Nikos Salingaros's Notes on Christopher Alexander

 

11、模式最佳的形式是什么?

    拿出你所精选的。多数的亚历山大模式表现为以下形式:

        假如  你发现你自己在  场景

            对于例子  例子

              问题

            使其承担  约束

        那么  因为某些  理由

            应用  设计形式和(或)规则

            来构建  解决方案

            推导出  新的场景    其它模式

    注,原文:

        IF   you find yourself in CONTEXT

                for example EXAMPLES,

                with PROBLEM,

                entailing FORCES

        THEN for some REASONS,

                apply DESIGN FORM AND/OR RULE

                to construct SOLUTION

                leading to NEW CONTEXT and OTHER PATTERNS

   

还有许多风格的变体。现存的讨论模式的书中没有两本使用完全相同的形式。可选的有包含纯粹的叙述性的波兰形式)。或许最流行的形式(在设计模式一书中使用)与此相反,他们开始于设计形式和(或)设计规则,然后才描述问题,场景,和他们怎样应用的例子。

 

    超越模式不同的形式,其结构和内容的共有要求包括:

 

    最佳实践 的描述

或者至少被广泛认可的实践 。有些人把模式看作一个为了构建权威性的软件工程手册的步骤。

    适度的普遍性

表明模式是会重复出现 的。这就要求你应该从几个已知的应用中抽象出东西来。在涉及二选一的模式时,这可能要求提及模式无法 应用的情况以及选择性的参考模式。

    范围

应用模式的场景要被完整的描述。恰当时,还可以包括典型的导致应用此模式的其它模式。

    建设性

模式这个词语的意思就是:一个让人们建立解决方案的实例的方法。某些情况下,可能需要具有表现基本关系的一系列图形。另外,可能还需要一系列步骤,以便模式的使用者可以按部就班,依照解决方案中应该出现的步骤的描述和(或)例子进行下去。

    完整性

        所有相关的约束都被描述到。

    实用

表明解决方案(solution)成功的解决了焦点问题(约束);或者当它们仅仅被部分的解决,并且(或者)当它们为可能应用的相关模式引入了新的约束、参考时。

    样例

        解决方案步骤的举例说明,以及现有软件中的应用实证

    适当的抽象

例如,“加入另一个中间层次”可能是有益的探究,但是它可能由于过于泛泛而且有多种可理解意义而不能成为好的模式。

    少一些创意

新的解决方案不是模式。(虽然导致产生模式的描述文档的“提取,综合,和改写”也许有新意。而且,虽然模式也可能导致产生新颖的用法。)

    合适的称谓

        简明的、描述性的名称可以有助于为开发人员提供共用的词汇表。

    清晰明了

好的叙述和风格很容易让人们判断出这个模式是否可以很好的工作并且怎样工作,因而他们自己就不必重新发明它(模式)了。

 

12、什么是约束(force)?

约束的概念概括了软件工程师用来校准设计和实现的各种准则。例如,在计算机科学中的经典算法研究中,主要约束(force)要解决的是效率(时间复杂度)。然而,模式处理的是大量的、难以度量的并且相互冲突的目标集,以及在你曾经创造每个作品的开发中遇到的约束。比如:

 

    正确性

l         解决方案的完整性和正确性

l         静态类型的安全,动态类型的安全

l         多线程的安全,生存期

l         容错性,事务能力

l         保密性,坚固性

    资源

l         效率:执行性能,时间复杂度,消息发送数,带宽需求

l         空间的利用:内存单元数,对象数,线程数,进程数,通信通道数,处理器数,...

l         递增量(需要时随选性on-demand-ness,此句有疑问

l         策略动态:公平性,平衡性,稳定性

    结构

l         模块性,封装性,耦合性,独立性

l         可扩充性:子类化能力,协调性,演化能力,可维护性

l         重用能力:开放性,整合性,轻便性,可嵌入能力

l         场景独立性(内聚性)

l         协同性

l         ...其它“能力特性”和“质量因素”   ##原文为:... other “ilities”and “quality factors”译注:我向原文 编者email询问,得到回复:”ilities” is a cute abbreviation for “reliability”, ”traceability”  , and several other software quality terms that end in “ility”. ##

    解释

l         易懂性,小巧程度,简单度,优雅性

l         实现的错误倾向

l         与其它软件共存

l         可维护性

l         在开发进程上(中)的影响    ## on/of ##

l         在开发团队的组织和发展上(中)的影响

l         用户参与上(中)影响

l         生产力,日程安排,花费上(中)的影响

    惯用法

l         习惯的规范

l         人为因素:学习能力,撤销能力,...

l         对于变化中的世界的适应性

l         审美

l         医疗和环境的影响

l         社会,经济和政治上的影响

l         ...其它的有关人类存在的影响

 

Tres Seaver补充道:惯用法远比软件要古老:在建筑行业,或者在机械/土木工程中,一个设计实体存在于一个相互作用的物理约束系统的关系中。对于某个约束问题没有得到解决的设计,连同整个的系统都会失败(例如,塔科马纽约湾海峡大桥坍塌,是因为没有解决大风导致的颤动;德克萨斯州A&M的大火,是因为没有考虑移动工人引起的负载##原文: the bonfire at Texas A&M failed to allow for the loads induced by moving workers ##)。延伸开去,设计必须满足复合体相互作用的需求和有时无法预料的情形;术语“约束”就是扩展开来包含这些情景。

 

 

13、什么是约束的分辨度?

亚历山大的模式描述包含了一个思想,就是模式应该描述一种平衡的约束。(甚至是亚历山大也被人(甚至是他自己)批评过,他一直没能提出令人信服的方法。)在计算机科学的分析与算法中,与此相同的概念是最优解的例子,但是它们却被用到前面提到的各种难以衡量的问题的约束描述中。

 

分析证明某个最优地解决了约束的解决方案是不可能的。(事实上,很难定义此处“证据”的概念,或者甚至很难看出这种证据有什么用处。)另一方面,也很容易得出“就是如此”的这种谎言,它提供了错误的或欺骗性的原理作为解决方案。甚至一些模式作者有时候不能完全理解为什么一个解决方案如此有效,或者不能评定它的适用范围。就像Ralph Johnson的文章中所说:

   

通常很难把一个模式解决的问题描述清楚。你可以断定它是一个模式,因为你经常看到它,而且你也知道它是一个好的模式,因为介绍它会给世界带来好处。但是当你注视世界时,你发现说出“为什么事情会如此”是很困难的。我想,弄清一个模式解答的问题的方法是:当我们设计东西时观察我们自己。什么是触发我们使用模式的条件?

 

我想,亚历山大为什么并不总是描述模式的问题的主要原因是:他并不是总是懂得的。那么,为什么GOF(4人小组)的书(设计模式)描述问题的不尽完善也是当然的。这并非形式上引导作者忽略问题,而是他们对问题的理解引导他们会写出何种形式。

   

    因为这些原因,模式社区需要下列支持的论据:

 

    经验证明是优的

那个解决方案已经在多个场景被合适的使用了。“3次规则”有时候被当作准则来用:不要认定某一些东西就是模式,除非你知道它在3个独立的地方被应用。

    对比

对于其他已知的解决方案或实践的比较。这些可能会包含一些证明了弱点或失败的例子,因为恰当的解决方案还没有被应用。

    独立的原创作者

        模式不应该由那些第一次发明或实现它们的人们记述。

    评论

让其他人批评,包括让密切相关的领域中的或不密切相关领域中的人们批评。一个模式评论的流行的形式(用在模式语言程序(PLOP)的讨论会)是Writer’s Workshop

 

只有提供了这些证据,一个模式有时候才可以称为“原型模式”(proto-pattern)——一个候选模式。

 

14、什么是无名质量(Quality Without A Name(QWAN))?

    对于这个问题没有又短又好的答案。你应该看看“持久的构建方式”(The Timeless way of building

   

十分讨厌的是模式的热衷者喜欢伪称亚历山大从来未写过关于QWAN的东西。十分古怪的是一些人喜欢伪称QWAN让模式同某些神秘事物紧密联系,听起来古怪的是形而上学的人鼓吹你要注意名称。

 

15、模式可否给出否定的形式,告诉你什么不该做?

也许理想状态下是不需要的 — 一套好的模式可以帮助你丢掉你提出来的许许多多糟糕的设计(有时被称为反模式:antipatterns),同样将一个给定的模式应用于所有的场景中,这也是不合适的。但是有一些想法非常有必要明确的指出来。一种方式是在模式描述中包含类似“常见的陷阱和缺陷”的章节。蹩脚解决方案(不相称的方案)的描述也能成为一个好的解决方案中的动机、基本原理和约束的组成部分。模式也可以描述从糟糕的解决方案到好的解决方案的改进过程(有时体现在“以前/以后”或者“修正”这样的章节中)。

 

16、模式是否可以介绍一些可选的解决方案而非单一的方案呢?

也许理想状态是不需要的 -- 因为每个解决方案应该紧密地关联于它的最佳应用场景。但是有时候那太难了。提及可选的解决方案还是比什么都不提及要好,因为可以建立起框架,通过探索那些不同解决方案的约束来进一步完善这个模式。甚至当它们不同时,在同一介绍中,是否组合一套模式,来共用多数场景和约束,这也是一个格式上的问题。

 

17、为什么费心写的模式归根结底就如同我祖母给我的建议?

因为一些模式非常优秀和有用,甚至连你的祖母都知道它们了。把它们记下来,把建议的场景、评价、和暗示变得比你的祖母所可能做的更加清晰明了。

 

18、所有的模式必须像某些模式一样[低级或高级、通用或特殊、抽象或具体]吗?

    当然不是。 

 

19、模式的理论基础是什么?

没有通常意义上的正式基础。模式表现的是滋生于各种理论和经验基础的设计思想。另外,许多指导模式的思想产生于跨越不同工程领域的经典或不是那么经典的“设计理论”著作。(详见在模式主页列出的书目清单)

 

20、模式可否用一些详细的形式和符号表示?

欢迎你去尝试,但要牢记的是,如果忽略了描述场景,忽略了要解决的问题,忽略了解决方案合理性的证明,忽略了构造或实现的指导方针,或者忽略了与其他模式的关系,那么这些形式符号化的设计规则或设计表现就不是模式了。

 

21、我为什么要使用模式?

和你重用好的代码的原因相同:一些人在理解场景(context)、约束(force)、解决方案(solution)中,相对你已投入或者想要投入的努力,他们付出的更多,你应该从他们的知识和经验中获益。此外,因为模式的适应性、可重用性要高于代码,你可以在由于特殊的场合而不能重用已有的组件的情况下利用模式建立软件。

模式还向开发者提供了一套通用的名称和概念来处理通常的开发问题,这样就加强了沟通。

 

22、拥有一些基于模式的CASE工具应该是个好事吧?

也许吧,但模式是围绕于人和人之间的交流的。假如这个媒介增强了同他人的沟通,那是很好的。如果它仅仅为了借助计算机提高模式的执行度,那就不值了。

 

23、一种模式语言和一套模式有什么不同?

    一种模式语言是一套相互关联的模式,[它们]共用相同场景,并且可能分类。

   

这个术语源由于亚历山大。亚历山大的“语言(language)”这个术语是不合惯例的,但却不是错误的。假如你以非正规角度来看,对它超形式化,模式条目其实就是“产品规则”。假如你记得你[学过]的自动化理论,你会记起那些规则是描述反复可列举语言的唯一途径。

 

24、为什么没有更多的关于任意的(WHATEVER)模式?

因为你还没有写出它们来。若你感兴趣,你很可能懂得一些东西,那么当你懂得了一些东西,你就能够写模式了。

 

25、我怎样开始写模式?

    下面是一些通常的建议:

l         避免为写模式而写模式。

l         找到一些你熟知的并且多次发生的事件和(或)记述的内容作为模式素材。或者相反,从现有的软件中挖掘出新的可能的模式。

l         检查是否其他人已经写出了相似的模式

l         注意模式的质量而非数量。

l         领会为什么模式会存在或被应用。

l         找出记录它的合理格式。

l         散发给其他人(例如,通过网页,模式讨论组,或者提交给邮件列表),并听取意见。

l         提交给媒体,例如PLOP,在作家工作室(writer's workshop)那儿可以得到评论。

l         不断的反复和提炼。

    另见:Ward Cunningham's Tips for Writing Pattern Languages

 

26、我怎么知道我的某个主意(或设计、构造)是一个模式?

    试试把它当作模式来写。Writing it as pattern.

 

27、现在有多少模式?

有些人认为,相对于几乎每个人都该知道的模式,还没有被发现的模式很少。某些人认为在更多的领域里,还有非常多的模式应该构建出来。这两个观点都可能正确。试着写一些更多的模式,让我们把它们找出来。

 

28、已有的众多模式不会产生在查找,分类,检索,使用和维护时的问题?

    也许。

 

29、我能否在[一些详细的面向对象的分析和设计的方法]中应用模式?

    大概可以。虽然假设你这样做了,你可以不必拘泥于很多符号的表示方法。

 

30、模式的应用是否需要有迭代?

大概,你可能非常幸运,针对你的问题已经有一套完整的模式,模式的每个应用都顺利进行,并走向最终的产品,而且没有回溯。但是人们从未这么幸运过。

 

31、与模式使用相关的开发过程,有可以推荐的吗?

大概如此:即便我们对此讨论很多,但是我们还是不知道(什么是被推荐的开发过程)。使用了模式,我们才能找出(这是不是要推荐的开发过程)。

 

32、模式在商业实践和软件行业中会有效吗?

    回答同上。(意思就是用了才知道)

 

33、是不是教人们写出模式要比教他们使用现有的模式更有效呢?

    两者都需要。没有哪一个比另一个更需要。

 

34、在我工作的地方我们怎样把模式的应用制度化?

    一般的建议包括:

l         为模式挖掘你拥有的最好的代码。

l         扩充设计文档,回顾实践经验,参与设计模式

l         把已有的设计模式用到实际情况中。[Run courses on the use of existing design patterns]

l         在“作家工作室”(writer's workshop)回顾已有的模式。

l         用基于模式风格的模板编写设计文档,这样它们就可以发展为模式。

l         建立一个学习小组,一星期聚会一次讨论模式。一旦爱好者的群体产生了,他们就会要求将其制度化了。

 

35、为什么亚历山大的模式未被建筑师广泛应用?

这可能并非是单一的原因造成的。人们列举的因素包括:同长期已建立的惯例冲突;同建筑师们的职业文化冲突;经济的因素;Alexander贯注于人们设计和建造自己的房子的事实;还有,关于模式语言中的特定的模式在实际中究竟有多大用处或多少好处,观点不尽相同。

 

36、你们能否在一个很大的开发中使用模式?

    已经有报导这样做了

37、模式是否被夸大了

    当然。这是难免的。

 

38、模式真的有用吗?

    请提出更明确的问题。

 

Doug Lea

最后更新: 2000.11.7 星期二 美国东部时间07:27:54