四人帮的设计模式至少使用文字处理器作为他们的一些模式的示例，特别是复合和享元。
除了使用 C 或 C++ 之外，您真的可以使用这些模式和它们需要的面向对象的开销来编写高性能的全功能文字处理器吗？
我知道 Eclipse 是用 Java 编写的，但我没有经常使用它，所以我不知道它是否像 Visual Studio 那样快，或者像具有基于 C++ 的文本编辑系统的那样优美。
我只使用 C++ 和 Java 作为示例。这个问题更多地与拥有大量内存对象的开销有关，就像在文字处理器甚至游戏等应用程序中那样。
设计模式以牺牲简约为代价促进抽象，尽管它们通常会指出您何时可能会受到某种性能影响。文字处理器，尤其是游戏，可以从尽可能接近金属中获得最大的好处。
我只是想知道是否有人知道不是用 C++ 编写的快速面向对象的文字处理器或文本编辑器，以及他们是否会使用模式构建一个，或者他们会放弃很多抽象的东西吗？
享元实际上只是在有数千个具有内在共享状态的对象的情况下节省资源的一种方式，因此它在比 C/C++ 更高级的语言中可能有用。也许 GoF 在文档中使用字形的示例并不是说明这种模式的最佳选择。
我认为构建高性能文字处理器不仅仅是这些基本模式 - 不确定GoF中是否有任何东西排除了能够成功地做到这一点。
一般来说，Visual Studio (VS) 比 Eclipse 更先进，性能也明显好于 Eclipse——至少是我见过的 VS 版本。Eclipse 是目前最令人印象深刻的 Java 应用程序之一，它在具有大量 RAM 的更新的机器上运行得相当好。
好吧，flyweight是一种在文字处理器中使用的荒谬模式。IIRC，他们将每个字符都作为对象引用[注意：它是针对每个glyph的，这仍然很疯狂，因为您的操作系统会很乐意为您绘制它]。如果指针比字符宽，并且所有处理都与间接相关，那么在文字处理器中以这种方式使用该特定模式会很疯狂。
如果您对文字处理器的设计感兴趣，我发现了一篇文章，该文章不涉及模式，但确实着眼于文字处理器设计和设计注意事项的一些数据结构。
试着记住设计模式是为了让你的生活更轻松，而不是为了让你变得纯粹。使用模式必须有理由，它必须提供一些好处。
一般而言，GoF 和模式的重点是谈论如何在正确的情况下“正确”地做事情，而不一定是“正确”的事情。如果性能是一个问题，并且您发现没有命名模式可以提供足够的性能，那么也许您可以证明自己走自己的路是合理的。但是对模式的良好了解会给你一个“合理的默认值”，并且可能意味着你牺牲清晰度/ SoC / 等只是为了提供足够的性能所必需的。
感觉你正在“偏离”规范会鼓励你 a) 三思而后行 b) 好好评论非惯用代码。
模式是至关重要的知识，但没有什么是福音，你必须始终运用判断力。
说了这么多——我想不出为什么你不能使用模式和现代 JDK 编写一个像样的文本编辑器
这个问题实际上似乎是关于 Java 与 C++ 的性能，这与其说是面向对象，不如说是在具有垃圾收集等的虚拟机上运行。
这份关于 Java 与 C++ 性能的白皮书可能值得一读。
您必须记住的一件事是 GoF 书是在 90 年代初编写的，当时流行的操作系统没有广泛的图形库。那时甚至 Windows 还不是操作系统。
IIRC GoF 于 1994 年发布。即使在 1994 年，Windows 95 Beta 也可用（并在我的 486DX33 上运行），而 Windows 3.x 大约在 1990 年就已经存在。
Eclipse + netbeans + IntelliJ 几乎都是用 java 或在 JVM（不是 C++）上运行的东西编写的。在其中至少 2 个 IDE 中，我花了一些时间处理编辑器代码，所以我可以向您保证它都是 java 的（而且也不容易）。
VS 2005 是我对 Visual Studio 的最后一次体验，即便如此，我仍然认为 eclipse 的响应速度更快（intelliJ 加倍地给了时间来预热和索引）。
不知道这有什么关系，但那是我的经验。但令我惊讶的是，Visual Studio 今天仍然是用 C++ 编写的——我认为使用 C# 符合微软的利益——如果没有别的，它会真正推动它的性能，就像吃自己的狗粮一样！
是的，当前的机器足够快，并且有足够的内存，这是可能的。如果您看一下 Squeak，您会看到一个用 Smalltalk 编写的 Smalltalk IDE，比 Java 慢得多，但仍然足够快。另一方面，高清视频编辑目前需要一些较低级别的支持。