你真的可以用 GoF 设计模式构建一个快速的文字处理器吗？答案

【问题标题】：Can you really build a fast word processor with GoF Design Patterns?你真的可以用 GoF 设计模式构建一个快速的文字处理器吗？
【发布时间】：2010-09-06 03:36:58
【问题描述】：

The Gang of Four 的 Design Patterns 使用文字处理器作为至少一些模式的示例，尤其是复合和享元。

除了使用 C 或 C++，您真的可以使用这些模式和它们需要的面向对象的开销来编写高性能的全功能文字处理器吗？

我知道 Eclipse 是用 Java 编写的，但我用得不多，所以我不知道它是否像 Visual Studio 那样快，或者像具有基于 C++ 的文本编辑系统的那样优美。

我只使用 C++ 和 Java 作为示例。这个问题更多地与拥有大量内存对象的开销有关，就像在文字处理器甚至游戏等应用程序中那样。

设计模式以牺牲简约为代价促进抽象，尽管它们通常会指出您何时可能会受到某种性能影响。文字处理器，尤其是游戏，可以从尽可能接近金属中获得最大的好处。

我只是想知道是否有人知道不是用 C++ 编写的快速面向对象的文字处理器或文本编辑器，以及他们是否会使用模式构建一个，或者他们会放弃很多抽象的东西?

【问题讨论】：

定义“快”，在 3+Ghz 4 核 8 线程上下文芯片作为商品的世界中，我挑战你写一个慢字处理器。
@fuzzy：我几乎同意你的看法，但我有一个 8 核 i7 和 12GB 内存，而且写得不好的商业软件仍然会找到运行缓慢的方法。
@fuzzy 这是一个愚蠢的挑战，没有指定任何约束。
visual studio 2010 在 WPF 中实现了一个基于 C# 的文本编辑器，这是主要的变化之一。

标签： java performance design-patterns ide text-processing

【解决方案1】：

这个问题实际上似乎是关于 Java 与 C++ 的性能，与其说是面向对象，不如说是在具有垃圾收集等的虚拟机上运行。

This whitepaper 关于 Java 与 C++ 性能的对比可能值得一读。

【讨论】：

如果您正在编写文字处理器或 IDE，本文的基准在很大程度上是无关紧要的。

【解决方案2】：

嗯，flyweight 是在文字处理器中使用的荒谬模式。 IIRC，他们将每个字符都作为一个对象引用 [注意：它是针对每个 glyph 的，这仍然很疯狂，因为您的操作系统会很乐意为您绘制它]。如果指针比字符宽，并且所有处理都与间接相关，那么在文字处理器中以这种方式使用该特定模式会很疯狂。

如果您对文字处理器的设计感兴趣，我发现了一篇文章，该文章不涉及模式，但确实查看了一些 data structures underlying word processor design and design considerations。

请记住，设计模式的存在是为了让您的生活更轻松，而不是为了让您变得纯粹。使用模式必须有理由，它必须提供一些好处。

【讨论】：

也许自己绘制单个字形而不是将其委托给操作系统可能听起来很疯狂，许多文本查看器和编辑更喜欢这样做。操作系统字形渲染例程可能会产生不太美观的结果。
不知道这是否是原始链接所指向的，但我能找到的最好的是cs.unm.edu/~crowley/papers/sds/sds.html
@ChristofSchardt：我想它现在在这里：bluemug.org/research/text.pdf

【解决方案3】：

享元实际上只是在有数千个具有内在共享状态的对象的情况下节省资源的一种方式，因此它可能在比 C/C++ 更高级别的语言中有用。也许 GoF 在文档中使用字形的示例并不是说明这种模式的最佳选择。

我认为构建高性能文字处理器不仅仅是这些基本模式 - 不确定 GoF 中是否有任何东西排除了能够成功地做到这一点。

一般来说，Visual Studio (VS) 比 Eclipse 更先进，性能也明显好于 Eclipse - 至少是我见过的 VS 版本。 Eclipse 是目前最令人印象深刻的 Java 应用程序之一，它在具有大量 RAM 的更新的机器上运行良好。

【讨论】：

其实是缩写GoF而不是GOF。
Eclipse 在启动时必须加载的插件越多，您的内存开销就越大。不幸的是（或者幸运的是，取决于您的观点），Eclipse 的更高版本和更高版本默认包含越来越多的插件，增加了开销，但也增加了功能。
“一般来说，Visual Studio (VS) 比 Eclipse 更先进，性能也好很多”en.wikipedia.org/wiki/Weasel_words

【解决方案4】：

您必须记住的一件事是，GoF 书是在 90 年代初编写的，当时流行的操作系统没有广泛的图形库。那时甚至 Windows 还不是操作系统。

IIRC GoF 于 1994 年发布。即使在 1994 年，Windows 95 Beta 也已推出（并在我的 486DX33 上运行），而 Windows 3.x 大约在 1990 年就已经存在。

【讨论】：

【解决方案5】：

Eclipse + netbeans + IntelliJ 几乎都是用 java 或在 JVM（不是 C++）上运行的 something 编写的。在其中至少 2 个 IDE 中，我花了一些时间来处理编辑器代码，所以我可以向您保证它都是 java 的（而且也不容易）。

VS 2005 是我对 Visual Studio 的最后一次体验，即便如此，我认为 eclipse 的响应性要快得多（intelliJ 加倍因此有时间预热和索引）。

不知道这有什么关系，但那是我的经验。但令我惊讶的是，Visual Studio 今天仍然是用 C++ 编写的——我认为使用 C# 符合微软的利益——如果不出意外的话，它会真正提高其性能，就像吃自己的狗粮一样！

【讨论】：

【解决方案6】：

总体而言，GoF 和模式的重点是谈论如何“正确”地做事，而不一定“正确”地做事。如果性能是一个问题，并且您发现没有命名模式可以提供足够的性能，那么也许您可以证明自己走自己的路是合理的。但是，对模式的深入了解可以为您提供“合理的默认设置”，并且可能意味着您牺牲清晰度 / SoC / 等只是为了提供足够的性能所必需的。

感觉自己“偏离”了规范会鼓励你 a) 三思而后行，b) 好好评论非惯用代码。

模式是至关重要的知识，但没有什么是福音，您必须始终运用判断力。

说了这么多——我想不出为什么你不能使用模式和现代 JDK 编写一个像样的文本编辑器

【讨论】：

【解决方案7】：

是的，目前的机器速度足够快，并且有足够的内存，这是可能的。如果您看一下 Squeak，您会看到一个用 Smalltalk 编写的 Smalltalk IDE，比 Java 慢得多，但仍然足够快。另一方面，高清视频编辑目前需要一些较低级别的支持。

【讨论】：