"四人帮"的设计模式以文字处理器为例，说明至少其中一些模式，尤其是"复合"和"轻量级"。

除了使用C或者C ++之外，我们是否真的可以使用这些模式以及它们所需要的面向对象的开销来编写高性能的全功能文字处理器？

我知道Eclipse是用Java编写的，但是我并没有使用太多，所以我不知道它的速度是否像Visual Studio一样快或者完美，它具有基于C ++的文本编辑系统。

我仅以C ++和Java为例。这个问题更多地涉及像在文字处理程序甚至游戏之类的应用程序中拥有大量内存对象的开销。

设计模式以牺牲简约性为代价来促进抽象，尽管它们通常指出何时可能会对性能造成一定影响。文字处理器，尤其是游戏，得益于尽可能接近金属的优势。

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

解决方案

回答

这个问题实际上似乎是关于Java与C ++的性能有关的，而不是面向对象的，而是在带有垃圾回收之类的虚拟机上运行的。

有关Java与C ++性能的白皮书可能值得一读。

回答

好吧，flyweight是在文字处理器中使用的一种荒谬模式。 IIRC，他们把每个字符都当作一个对象来引用[注意：它是针对每个字形的，这仍然很疯狂，因为OS会为我们高兴地绘制它]。用指针比一个字符，所有间接关联的处理更广泛的，你是疯了使用该特定模式的方式在一个文字处理器。

如果我们对文字处理器的设计感兴趣，那么我会找到一篇不涉及模式的文章，而是介绍了文字处理器设计和设计注意事项中的一些数据结构。

尝试记住，设计模式可以使生活更轻松，而不是让我们变得单纯。必须有使用某种模式的理由，它必须提供一些好处。

回答

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

我认为，构建高性能的文字处理器不只是这些基本模式，还有很多，尽管不能确定GoF中是否有任何东西可以成功做到这一点。

通常，Visual Studio(VS)更先进，并且至少比Eclipse(我见过的VS版本)好得多。 Eclipse是目前最令人印象深刻的Java应用程序之一，它在具有大量RAM的最新机器上运行得很好。

回答

One of the things you have to remember was that the GoF book was written in the early 90s, when the prevalent OSes did not have extensive graphic libraries. Even Windows was not yet an OS at that time.

IIRC GoF于1994年发布。即使在1994年，Windows 95 Beta仍然可用(并在我的486DX33上运行)，而Windows 3.x大约在1990年就出现了。

回答

Eclipse + netbeans + IntelliJ几乎都是用Java或者在JVM(非C ++)上运行的东西编写的。在这些IDE中的至少两个中，我花了一些时间使代码，因此可以向我们保证所有的Java(而且也不容易)。

VS 2005是我对Visual Studio的最后一次体验，即使到那时，我仍然认为Eclipse的响应能力要强得多(intelliJ倍加加倍，因此有足够的时间进行预热和编制索引)。

不确定多数民众赞成在哪些方面，但是多数民众赞成在我的经验上。但是令我惊讶的是，Visual Studio仍然今天仍然是用C ++编写的，我认为使用Cif符合微软的利益，没有其他事情会真正地提高其性能，就像吃自己的狗粮！

回答

通常，GoF和模式的重点是谈论如何正确地做"正确"的事情，而不是根据情况正确地做"正确"的事情。在性能是一个问题的情况下，我们会发现没有任何命名模式可以提供足够的性能，那么也许我们可以证明按自己的方式行事。但是，对模式的充分了解会为我们提供"合理的默认值"，并且可能意味着我们仅牺牲透明度/ SoC /等来提供足够的性能。

感觉到我们正在"偏离"规范会鼓励我们a)三思，并且b)很好地注释非惯用的代码。

模式是至关重要的知识，但是什么都不是福音，我们必须始终运用判断力。

说了这么多，我无法想到我们为什么不能使用模式和现代JDK编写体面的文本编辑器的任何原因

回答

是的，当前的计算机速度足够快，并且具有足够的内存。如果我们看一下Squeak，就会发现用Smalltalk编写的Smalltalk IDE，比Java慢得多，但仍然足够快。另一方面，高清视频编辑目前需要一些较低级别的支持。