我目前正在学习设计模式考试(明天将举行......)。在“测试考试”之一中,我发现了以下问题:
Jim Coplien 在特邀演讲中表示,GoF 书中甚至没有一种设计模式。您对此有何看法?
因为我没有参加这个特别的讲座(那是上学期;)我不知道他的意思。我没有证据表明 Jim Coplien 说过,但我认为这无关紧要。
你认为他对这句话的意思是什么?
(我不确定这个问题是否适合这个论坛,但是,我想问一下。)
我目前正在学习设计模式考试(明天将举行......)。在“测试考试”之一中,我发现了以下问题:
Jim Coplien 在特邀演讲中表示,GoF 书中甚至没有一种设计模式。您对此有何看法?
因为我没有参加这个特别的讲座(那是上学期;)我不知道他的意思。我没有证据表明 Jim Coplien 说过,但我认为这无关紧要。
你认为他对这句话的意思是什么?
(我不确定这个问题是否适合这个论坛,但是,我想问一下。)
GoF 声称从克里斯托弗·亚历山大 (Christopher Alexander) 那里获得了图案灵感(正如他们在书的开头所说的那样),他在更广泛的设计领域推广了这个术语。对亚历山大来说,模式:永远是模式语言的一个元素;有助于加深人的感情;并且本质上总是几何的。至少有一些 GoF 模式在其中至少一个点上失败了,并且有几个在所有三个点上都失败了。尽管“模式”是一个中性的英语单词,但 GoF 作品的文化和历史根源,加上他们对亚历山大灵感的援引,使其受制于其祖先的基本标准,因而显得缺乏。即使他们知道并表示他们知道,他们与亚历山大有些分歧,但他们仍然选择使用他精心设计、研究和推广的术语,我要他们对此负责。(也就是说,他们都是重要的熟人;我与几年前失去的 John Vlissides 关系密切,并与 Richard Helm 和 Eric Gamma 就这背后的更深层次问题进行了很好的对话。我与 Ralph 的讨论不太有趣因为他们停留在工程级别。)
言语意味着事情。GoF(或整个软件社区)在写这本书时并没有很好地理解亚历山大对“模式”一词的理解,但他们建立在对时间的粗俗看法的基础上,这基于三个来源: 1. Erich Gamma博士论文;2. Ralph Johnson 的框架工作,以及 3. C++ idioms book(你可以在 GoF book 的第 6.3 节对其来源的解释中找到这个)。(哦,Knuth 也有影响。)我继续向作者提出质疑,但人们喜欢它,他们喜欢人们喜欢它,所以势头继续。
几年后(2004 年 12 月 2 日),一位 GoF 会写信给我,描述他“啊哈”的经历,最终理解了亚历山大试图传达的内容。这与 GoF 书的内容有很大不同:
终于通过漫长曲折的路线摸索了“生成模式”和零碎的增长……主要是通过软件的一些有趣的通用属性(无标度和小世界)
有时我有点慢...但最终到达那里...
不幸的是,人们发现它们有用是对现代编程语言的一种控诉。这些语言没有适当的结构来表达 Alexander 认为是模式特征的破坏对称性,这是复杂设计所固有的(秩序的本质,第 187 页:“ ……一般来说,一个大的对称性简化的新古典主义类型很少对事物的生命做出贡献,因为在世界上任何复杂的整体中,几乎总是有复杂的、不对称的力量在起作用——位置、背景和功能的问题——需要打破对称性” ;同上,第 63-4 页:“自然也创造了美丽的结构,这些结构是通过重复应用结构保持转换来控制的。在这方面,我认为有必要说一下我所说的结构保持变换与物理学中所谓的“对称破缺”密切相关。”)。Java 在这方面特别糟糕,但它的祖先 Smalltalk 也是如此。C++ 有丰富的特性来描述局部对称性破坏,但大多数人并不真正知道如何使用它们。Richard Gabriel - 他也与 Alexander 密切合作,并且拥有像 CLOS 和 Scheme 这样的语言值得称赞的人 — 说他根本不理解 GoF 模式,因为设计合理的语言(如 CLOS 或 Scheme)不需要它们。我基本上属于同一个阵营。
这背后有很多设计理论可以追溯到设计运动(Thackara(“现代主义之后的设计”,1989 年)、Naur、Alexander、Cross(“设计方法论的发展”,1984 年)和 1980 年代的其他作者)。鉴于当时设计运动工作的明显发现,程序员对这些文献知之甚少,而 CS 思维有多么错误,这总是让我感到惊讶。我们这些在 1993 年创立模式学科(The Hillside Group 的最初 7 个)的人都熟悉这些文献的主要主题。PLoP 会议演变出大量从这些基础彻底演变而来的文献,更关注神秘的知识,而不是亚历山大寻求的“无名质量”。
我为 C++ 程序员介绍习语的原因是为了让他们在语言遇到障碍时进行面向对象的编程。现在,我们有了更强大的方法,例如 DCI,大大减少了对成语的需求。模式仍然适用于域级别——这符合 Alexander 的愿景。已经编写了一些很好的模式语言;例如,Hanmer(容错软件的模式,2007 年);由 Eloranta 等人撰写。(设计分布式控制系统,2014 年),以及 Alexander 自己指出的组织模式符合必要的标准(Coplien 和 Harrison,2004 年)。
Alexander 和我(以及 Richard Gabriel——阅读了他的“软件模式”——以及其他人)对这个在被 GoF 重新定义之前在设计中已经确立的术语的早期重定向感到失望。是的,因为他们称它们为设计模式,它们就是设计模式——在任何关于四人组的设计模式书的讨论中。在更广泛的设计理论和架构方案中,它们不是:它们只是成语。正如作者自己所说,他们就是这样开始的。
正在努力恢复 Alexander 对软件社区的愿景。ScrumPLoP® 社区 ( http://scrummplop.org ) 非常重视所有亚历山大式的模式基础。亚历山大的一位老同事 Greg Bryant 曾经为 CES 做 IT 方面的工作,他联系了我,告诉我他的工作是为了让 Alexander 的愿景重新回到软件中,我们即将交换票据。我敢肯定迪克·加布里埃尔总是有一些想法,尽管他和我已经有一段时间没有聊天了。与此同时,我继续与亚历山大的同事中野博直接合作,他将亚历山大的想法(他直接用永恒的道德经表达)) 直接进入他们在日本文化中的相似之处。这比试图将其硬塞进西方文化要好得多。这可能解释了我在理解我的主张时的一些挫败感——尽管这不是从事知识业务的专业人士的借口。
当然,所有这些基础都是发表的辩证法和研究的问题,任何愿意花时间研究它的人都可以使用。它不像这里那样随意,可以很快被驳回。我花了 20 年的时间——而且我可以直接接触到资源。我可以理解普通程序员很难深入研究这些东西,但我建议在放弃一个经过充分研究的职位之前做更多的研究,然后再做功课。这是 StackOverflow 的事情。
根据 GoF 自己的定义,它充满了设计模式。因此通过推断,Coplien 对设计模式有不同的定义,或者 Coplien 误解或歪曲了 GoF 的定义,或者他认为 GoF 的定义与 GoF 模式不匹配。
该问题邀请您描述两个定义之间的差异,并就您更喜欢哪个定义提供您的意见。可能您的合理意见,就像在学术界一样,您提出意见的理由(方法)比意见本身重要得多。