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

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

我认为构建高性能文字处理器的意义远不止这些基本模式——但我不确定GoF中是否有任何东西排除了成功实现这一点的可能性。

一般来说,Visual Studio(VS)比Eclipse更高级,性能也明显更好——至少是我见过的VS版本。Eclipse是最令人印象深刻的Java应用程序之一,它在具有大量RAM的最新机器上运行得很好。

好, flyweight 在文字处理器中使用这种模式是荒谬的。IIRC,他们将每个字符都作为一个对象引用[注:这是为每个 象形文字 ,这仍然很疯狂,因为你的操作系统会很乐意为你绘制它]。由于指针比字符宽,并且所有处理都与间接性相关,在文字处理器中以这种方式使用这种特定模式会很疯狂。

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

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

一般来说,GoF和模式的重点是谈论如何做正确的事情,而不一定是针对具体情况的正确的事情。如果性能是一个问题,并且您发现没有命名模式能提供足够的性能,那么也许您可以证明走自己的路是合理的。但是,对模式的良好了解会给你一个“合理的默认值”,这可能意味着你只会在提供足够性能所必需的范围内牺牲清晰度/SoC/等。

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

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

话虽如此,我想不出为什么你不能使用模式和现代JDK编写一个像样的文本编辑器

你必须记住的一件事是,GoF这本书写于90年代初,当时流行的操作系统没有广泛的图形库。当时,Windows还不是一个操作系统。

IIRC GoF于1994年获释。甚至在1994年,Windows 95测试版就已经推出(并在我的486DX33上运行),而Windows 3.x大约从1990年就已经出现了。

Eclipse+netbeans+IntelliJ几乎都是用java编写的 某物 它在JVM(而不是C++)上运行。在其中至少两个IDE中,我花了一些时间处理编辑器代码,所以我可以向你保证它都是java的(而且也不容易)。

VS 2005是我最后一次使用visual studio,即使在那时,我也认为eclipse的响应速度要快得多(intelliJ有双倍的时间进行预热和索引)。

不知道这有多重要,但这是我的经验。但我很惊讶visual studio今天仍然是用C++编写的——我认为使用C#符合微软的利益——如果没有别的办法,它真的会提高它的性能,一点也不像吃自己的狗粮!

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

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

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