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

Question

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.

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?

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.

Answer 1

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.

This whitepaper on Java vs. C++ performance might be worth a read.

Answer 2

Well, flyweight is a ridiculous pattern to use in a word processor. 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]. 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.

Answer 3

I only used C++ and Java as examples. 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?

Answer 4

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++. Maybe the GoF's example using glyphs in a document was not the best choice to illustrate this pattern.

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.

Generally, Visual Studio (VS) is more advanced and performs significantly better than Eclipse - at least, the versions of VS that I have seen. Eclipse is one of the most impressive Java applications out there though, it runs quite well on more recent machines with lots of RAM.

Answer 5

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 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.

Answer 6

Eclipse + netbeans + IntelliJ all are written pretty much all in java or something that runs on the JVM (not 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).

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).

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 !

Answer 7

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. 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.

Feeling that you are "deviating" from the norm encourages you to a) think twice, and b) comment the non-idiomatic code well.

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

Answer 8

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. HD video editing on the other hand is something that currently has a need for some lower-level support.