你真的能用gof设计模式构建一个快速的字处理器吗?

飞重确实是一种节约资源的方式,在有数千个具有固有共享状态的对象的情况下,它可能比C/C++更有用于高级语言。也许在文档中使用glyph的GOF示例不是演示此模式的最佳选择。

不过,我认为构建高性能的字处理器比构建这些基本模式要多得多——不确定GoF中是否有任何东西排除了成功实现这一点的可能性。

通常,Visual Studio(VS)比Eclipse更高级,性能也明显更好——至少我见过的VS版本。Eclipse是其中最令人印象深刻的Java应用之一,它运行在相当多的RAM上的机器上运行良好。

好, flyweight 在文字处理机中使用是一种荒谬的模式。IIRC,他们把每个字符作为一个对象引用[注:它是为每个 字形 这仍然是疯狂的,因为你的操作系统会很乐意为你画出来。如果指针比字符宽,并且所有与间接寻址相关的处理,那么在字处理器中以这种方式使用特定的模式就太疯狂了。

如果您对字处理器的设计感兴趣,我发现了一篇文章,它不涉及模式,但确实研究了 data structures underlying word processor design and design considerations .

试着记住设计模式是为了让你的生活更容易,而不是为了让你变得纯洁。必须有一个使用模式的理由,它必须提供一些好处。

一般来说,gof和模式的要点是讨论如何做正确的事情,而不一定是“正确”的事情,因为在正确的情况下。如果性能是一个问题,并且您发现没有命名的模式能够提供足够的性能,那么也许您可以证明自己的方法是正确的。但是,对模式有很好的了解会给您一个“合理的默认”,这可能意味着您只需要牺牲足够的清晰度/soc/etc就可以获得足够的性能。

感觉自己“背离”了规范,会鼓励您a)三思而后行,b)对非惯用代码进行良好的评论。

模式是最重要的知识,但没有什么是福音,你必须始终运用判断。

说了这么多-我想不出任何理由为什么你不能用模式和现代JDK编写一个像样的文本编辑器。

你必须记住的一件事是,GOF的书是在90年代早期写的,当时流行的OSE没有广泛的图形库。当时甚至Windows还不是操作系统。

IIRC GoF于1994年发布。即使在1994年Windows95测试版也可以使用(并在我的486dx33上运行),Windows3.x大约从1990年就已经出现了。

Eclipse + NETBea+IntLyJ都是用Java编写的。 某物 它运行在JVM(不是C++)上。在至少2个IDE中,我花了一些时间在编辑器代码上,所以我可以向您保证它是所有的Java(并且它也不容易)。

vs 2005是我在Visual Studio上的最后一次体验,即使是在那时,我仍然认为Eclipse的响应性更高(Intellij提供了双倍的预热和索引时间)。

不知道这有多重要,但这是我的经验。但我惊讶的是,Visual Studio现在仍然用C++编写——我想用C语言来实现微软是有意思的——如果没有别的东西能真正推动它的性能,那就不必像吃自己的狗食了。

是的,当前的机器足够快,并且有足够的内存,这是可能的。如果你看一下Squeak,你会看到SimultTalk IDE写在SimultTalk中,明显比Java慢,但仍然足够快。另一方面,高清视频编辑是目前需要一些较低级别的支持。

这个问题实际上是关于Java和C++的性能,这不是面向对象,而是运行在带有垃圾收集的虚拟机上。

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