design-patterns - GoF中是否有任何模式？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

5年前关闭。




Improve this question




我目前正在学习设计模式考试(明天将举行......)。在其中一项“测试考试”中，我发现了以下问题:

Jim Coplien said during the invited lecture that there is not even one design pattern in the GoF book. What is your opinion about this?

因为我没有参加这个特定的讲座(这是上学期；)我不知道他可能是什么意思。我没有证据表明 Jim Coplien 说过，但我认为这无关紧要。

你认为他这句话是什么意思？

(我不确定这个问题是否适合这个论坛，但是，我想问。)

Answer 1

模式:这个概念 Root 于亚历山大的作品

GoF 声称其图案灵感来自克里斯托弗·亚历山大(Christopher Alexander)(正如他们在本书的前言中所说)，后者在更广泛的设计领域推广了该术语。对亚历山大来说，模式:永远是模式语言的一个元素；有助于深刻的人类情感；并且本质上总是几何的。至少有一些 GoF 模式在这些点中的至少一个上失败，并且有几个在所有三点上都失败了。虽然“模式”是一个中性的英语单词，但 GoF 作品的文化和历史根源，加上他们对亚历山大灵感的引用，让它受到其祖先的基本标准的判断，并且缺乏。尽管他们知道并表示他们知道他们与亚历山大有些不同，但他们仍然选择使用他精心设计、研究和推广的术语，我认为他们对此负责。 (也就是说，他们都是重要的熟人；我与几年前失去的 John Vlissides 关系密切，并与 Richard Helm 和 Eric Gamma 就这背后的更深层次的问题进行了很好的对话。我与 Ralph 的讨论没有那么有趣因为他们停留在工程级别。)

历史根源

言语意味着事物。 GoF(或整个软件社区)在撰写本书时并未很好地理解亚历山大式对“模式”一词的理解，但他们建立在对时间的粗俗看法之上，这种看法基于三个来源: 1、Erich Gamma博士论文； 2. Ralph Johnson 的框架工作，以及 3. C++ idioms 书(您可以在 GoF 书的第 6.3 节对其来源的解释中找到它)。 (哦，Knuth 也是一种影响。)我继续向作者提出质疑，但人们喜欢它，他们喜欢人们喜欢它，所以势头继续。

几年后(2004 年 12 月 2 日)，其中一位 GoF 会写信给我，描述他“啊哈”的经历，最终理解了亚历山大试图传达的意思。这与 GoF 书的内容有很大不同:

Finally grok'ed "generative patterns" and piecemeal growth through a long tortuous route.... Largely through some interesting universal properties of software (scale-free and small-worldness)

A bit slow I am sometimes... but got there in the end...

GoF 模式解决了偶然而非本质的复杂性问题

不幸的是，人们发现它们很有用，这是对现代编程语言的控诉。这些语言没有适当的结构来表达 Alexander 认为是模式特征的破坏对称性，而这些是复杂设计所固有的(Nature of Order，第 187 页:“......总的来说，简化的新古典主义类型很少对事物的生命作出贡献，因为在世界上任何复杂的整体中，几乎总是有复杂的、不对称的力量在起作用——位置、背景和功能——需要打破对称性” ; op cit., pp. 63-4: “自然也创造了美丽的结构，这些结构是由重复应用结构保持变换控制的。在这方面，我认为有必要指出我所谓的结构保持变换与物理学中众所周知的“对称破缺”密切相关。”)。 Java 在这方面特别糟糕，但它的祖先 Smalltalk 也是如此。 C++ 有丰富的特性来描述局部对称性破坏，但大多数人并不真正知道如何使用它们。理查德·加布里埃尔(Richard Gabriel)——他也曾与亚历山大密切合作，并且拥有 CLOS 和 Scheme 等语言——说他根本不理解 GoF 模式，因为设计合理的语言(如 CLOS 或 Scheme)不需要它们.我主要在同一个阵营。

设计运动

这背后有很多设计理论可以追溯到设计运动(Thackara(“现代主义之后的设计”，1989 年)、Naur、Alexander、Cross(“设计方法论的发展”，1984 年)和 1980 年代的其他作者)。令我惊讶的是，程序员对这些文献知之甚少，鉴于此时设计运动工作的明显发现，许多 CS 思维是多么错误。我们这些在 1993 年创立模式学科(The Hillside Group 的最初 7 个)的人都熟悉这些文献的主要主题。 PLoP session 发展了一系列从这些基础上演变而来的文献，更侧重于神秘的知识，而不是亚历山大所寻求的“无名的品质”。

习语的起源

我为 C++ 程序员引入习语的原因是允许他们在语言遇到障碍时进行面向对象的编程。现在，我们有了更强大的方法，比如 DCI，可以大大减少对习语的需求。模式仍然适用于域级别——这符合 Alexander 的愿景。已经编写了一些很好的模式语言；例如，由 Hanmer(容错软件模式，2007 年)；由 Eloranta 等人撰写。 (设计分布式控制系统，2014 年)，而亚历山大本人指出的组织模式符合必要的标准(Coplien 和 Harrison，2004 年)。

战斗失败，但工作仍在继续

Alexander 和我(以及 Richard Gabriel——阅读他的“软件模式”——以及其他人)都对这个早期重新定义一个在 GoF 重新定义之前在设计中已经确立的术语感到失望。是的，因为他们称它们为设计模式，它们是设计模式——在任何关于四人帮的《设计模式》一书的讨论中。在更广泛的设计理论和建筑方案中，它们不是:它们只是习语。即使正如作者自己所说，他们就是这样开始的。

有几项努力正在恢复 Alexander 对软件社区的愿景。 ScrumPLoP® 社区 ( http://scrumplop.org) 非常重视模式的所有亚历山大式基础。曾经为 CES 做 IT 工作的亚历山大老同事 Greg Bryant 联系了我，告诉我他的工作是将 Alexander 的愿景带回软件中，我们即将交换意见。我确信 Dick Gabriel 也总是有一些想法，尽管他和我已经有一段时间没有聊天了。与此同时，我继续直接与亚历山大的同事中野博 (Hiroshi Nakano) 合作，他将亚历山大的思想(他直接用《永恒》中的《道德经》表达)直接与日本文化中的相似之处联系起来。这比试图将其硬塞进西方文化要好得多。这可能解释了我在理解我的主张时的一些挫败感——尽管这不是知识行业专业人士的借口。

对提示者的劝勉

当然，所有这些基础都是已发表的辩证法和研究问题，任何愿意花时间研究它的人都可以使用。这不是一件随随便便的事情，就像这里一样可以很快被驳回。我花了 20 年的时间——我可以直接访问资源。我可以理解，普通程序员很难深入研究这些东西，但我建议在做作业之前，在立即解雇一个经过充分研究的职位之前，多做一些研究。这是 StackOverflow 的事情。