简体   繁体   English

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

[英]Can you really build a fast word processor with GoF Design Patterns?

The Gang of Four's Design Patterns uses a word processor as an example for at least a few of their patterns, particularly Composite and Flyweight. Gang of Four的设计模式使用文字处理器作为其中至少一些模式的示例,尤其是Composite和Flyweight。

Other than by using C or C++, could you really use those patterns and the object-oriented overhead they entail to write a high-performing fully featured word processor? 除了使用C或C ++之外,你真的可以使用这些模式和面向对象的开销来编写一个高性能的全功能文字处理器吗?

I know that Eclipse is written in Java but I haven't used it much so I don't know if it's all that fast or as polished as something like Visual Studio, which has a C++ based text editing system. 我知道Eclipse是用Java编写的,但是我还没有使用它,所以我不知道它是否像Visual Studio这样具有基于C ++的文本编辑系统那样快速或完美。


I only used C++ and Java as examples. 我只使用C ++和Java作为例子。 The question has more to do with the overhead of having a lot of in-memory objects like you would in an application such as a word processor or even a game. 这个问题更多地与拥有大量内存中对象的开销有关,就像在文字处理器甚至游戏等应用程序中那样。

Design patterns promote abstraction at the expense of parsimony even though they usually point out when you might take some kind of performance hit. 设计模式以简约性为代价促进抽象,即使它们通常会指出何时可能会遇到某种性能损失。 Word processors and especially games get the most benefit from being as close to the metal as possible. 字处理器,尤其是游戏,尽可能接近金属,从中获益最多。

I was just wondering if anyone knew of an fast object-oriented word processor or text editor that wasn't written in C++, and whether they'd build one using patterns or would they forgoe a lot of the abstracting away of things? 我只是想知道是否有人知道一个快速的面向对象的文字处理器或文本编辑器不是用C ++编写的,他们是否使用模式构建一个或者他们会放弃大量的抽象事物?

Flyweight really is just a way of conserving resources in situations where there are thousands of objects with intrinsic shared state, so it could be useful in higher level languages than C/C++. Flyweight实际上只是在存在数千个具有内在共享状态的对象的情况下节省资源的一种方式,因此它在高级语言中可能比C / C ++更有用。 Maybe the GoF's example using glyphs in a document was not the best choice to illustrate this pattern. 也许GoF在文档中使用字形的示例并不是说明这种模式的最佳选择。

I think there's a lot more to building a high performance word processor than just these basic patterns though - not sure whether there is anything in GoF that rules out being able to successfully do this. 我认为构建高性能文字处理器不仅仅是这些基本模式还有很多 - 不确定GoF中是否有任何东西可以排除能够成功实现这一目标。

Generally, Visual Studio (VS) is more advanced and performs significantly better than Eclipse - at least, the versions of VS that I have seen. 通常,Visual Studio(VS)比Eclipse更高级,性能也更好 - 至少是我见过的VS版本。 Eclipse is one of the most impressive Java applications out there though, it runs quite well on more recent machines with lots of RAM. Eclipse是最令人印象深刻的Java应用程序之一,它在具有大量RAM的最新机器上运行良好。

Well, flyweight is a ridiculous pattern to use in a word processor. 嗯, flyweight是一个在文字处理器中使用的荒谬模式。 IIRC, they had each character being referenced as a object [note: it was for each glyph , which is still crazy because your OS will happily draw that for you]. IIRC,他们将每个角色都作为一个对象引用[注意:它是针对每个字形的 ,这仍然是疯狂的,因为你的操作系统很乐意为你绘制]。 With a pointer being wider than a character and all the processing associated with indirection, you'd be mad to use that particular pattern that way in a word processor. 用指针比一个字符,并与间接相关联的所有处理更广泛的,你是疯了使用特定的模式在文字处理的方式。

If you're interested in the design of word processors, I found an article that doesn't address patterns but does look at some of the data structures underlying word processor design and design considerations . 如果您对字处理器的设计感兴趣,我发现一篇文章没有解决模式问题,但确实研究了一些基于字处理器设计和设计考虑因素数据结构

Try to remember that design patterns are there to make your life easier, not for you to be pure. 尽量记住,设计模式可以让您的生活更轻松,而不是让您变得纯洁。 There has to be a reason to use a pattern, it has to offer some benefit. 必须有一个使用模式的理由,它必须提供一些好处。

The point of GoF and patterns in general is to talk about how to do things "right" as in correct, not necessarily "right" as in right for the circumstances. 一般来说,GoF和模式的关键在于谈论如何做正确的“正确”事情,而不是正确的“正确”事情。 Where performance is an issue, and you find that no named pattern gives adequate performance, then perhaps you can justify going your own way. 如果性能是一个问题,并且您发现没有命名模式可以提供足够的性能,那么也许您可以证明以自己的方式行事。 But a good knowledge of patterns gives you a "sensible default" and will probably mean that you sacrifice clarity / SoC / etc only so much as is necessary to give adequate performance. 但是对模式的良好了解会给你一个“合理的默认”,并且可能意味着你只需要牺牲清晰度/ SoC /等就可以提供足够的性能。

Feeling that you are "deviating" from the norm encourages you to a) think twice, and b) comment the non-idiomatic code well. 感觉你“偏离”常规会鼓励你a)三思而行,b)很好地评论非惯用代码。

Patterns are vital knowledge, but nothing is gospel and you must always apply judgement. 模式是至关重要的知识,但没有什么是福音,你必须始终运用判断力。

Having said all that - I can't think of any reason why you couldn't write a decent text editor using patterns and a modern JDK 说了这么多 - 我想不出为什么你不能使用模式和现代JDK编写一个体面的文本编辑器

This question actually seems to be about Java vs. C++ performance, and that's not the object orientation so much as running on a virtual machine with garbage collection and such. 这个问题实际上似乎是关于Java与C ++的性能,而不是像在垃圾收集等虚拟机上运行那样的对象取向。

This whitepaper on Java vs. C++ performance might be worth a read. 关于Java与C ++性能的白皮书可能值得一读。

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. 你必须要记住的一件事是GoF书是在90年代早期写的,当时流行的操作系统没有广泛的图形库。 Even Windows was not yet an OS at that time. 甚至Windows当时还不是一个操作系统。

IIRC GoF was released in 1994. Even in 1994 Windows 95 Beta was available (and running on my 486DX33) and Windows 3.x had been around since roughly 1990. IIRC GoF于1994年发布。即使在1994年,Windows 95 Beta也可用(并在我的486DX33上运行),Windows 3.x自1990年左右开始出现。

Eclipse + netbeans + IntelliJ all are written pretty much all in java or something that runs on the JVM (not C++). Eclipse + netbeans + IntelliJ all几乎都是用Java编写的,或者在JVM(而不是C ++)上运行的东西 In at least 2 of those IDEs I have spent some time with the editor code, so I can assure you its all java (and its not easy either). 至少有2个IDE我花了一些时间使用编辑器代码,所以我可以向你保证它的所有java(也不容易)。

VS 2005 was my last experience of visual studio, and even then I thought eclipse was much more responsive (intelliJ doubly so given time to warm up and index). VS 2005是我对视觉工作室的最后一次体验,即便如此,我认为eclipse的响应速度要快得多(智能加倍,所以给予时间热身和索引)。

Not sure how thats relevant but thats my experience. 不确定那是多么相关,但这就是我的经验。 But I am surprised visual studio is still today written in C++ - I would think that it would be in Microsoft's interest to use C# - if nothing else it would really push its performance hard, nothing like eating your own dog food ! 但令我感到惊讶的是,今天仍然使用C ++编写的视觉工作室 - 我认为使用C#符合微软的利益 - 如果没有别的东西它会真正推动它的表现,就像吃自己的狗粮一样!

Yes, current machines are fast enough and have enough memory that that is possible. 是的,当前的机器足够快,并且有足够的内存,这是可能的。 If you take a look at Squeak, you see a Smalltalk IDE written in Smalltalk, significantly slower than Java, but still fast enough. 如果你看看Squeak,你会看到一个用Smalltalk编写的Smalltalk IDE,它比Java慢得多,但仍然足够快。 HD video editing on the other hand is something that currently has a need for some lower-level support. 另一方面,高清视频编辑目前需要一些较低级别的支持。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM