本当に GoF デザイン パターンを使用して高速ワード プロセッサを構築できますか?

Question

四人のギャング デザインパターン は、少なくともいくつかのパターン、特にコンポジットとフライウェイトの例としてワード プロセッサを使用しています。

C または C++ を使用する以外に、これらのパターンとそれに伴うオブジェクト指向のオーバーヘッドを使用して、高性能のフル機能のワード プロセッサを作成できるでしょうか?

Eclipse が Java で書かれていることは知っていますが、あまり使ったことがないので、C++ ベースのテキスト編集システムを備えた Visual Studio のようなものと同じくらい高速なのか、それとも洗練されているのかわかりません。

---

C++ と Java は例としてのみ使用しました。この問題は、ワード プロセッサやゲームなどのアプリケーションで発生するような、メモリ内オブジェクトが多数存在することによるオーバーヘッドと関係があります。

デザイン パターンは、通常、パフォーマンスに何らかの影響が出る可能性があることを示しますが、節約を犠牲にして抽象化を促進します。ワードプロセッサ、特にゲームは、金属にできるだけ近づけることで最大のメリットを得ることができます。

C++ で書かれていない高速なオブジェクト指向のワード プロセッサやテキスト エディタを知っている人はいるだろうか、パターンを使用してそれを構築するだろうか、それとも物事の抽象化を大幅に省略するだろうか、と疑問に思ったのです。

Answer 1

Flyweight は実際には、固有の共有状態を持つオブジェクトが数千ある状況でリソースを節約する方法にすぎないため、C/C++ よりも高水準の言語で役立つ可能性があります。おそらく、文書内でグリフを使用する GoF の例は、このパターンを説明するのに最適な選択ではなかったのでしょう。

ただし、高性能ワード プロセッサを構築するには、これらの基本的なパターン以外にも多くのことが必要だと思います。GoF にこれを成功させることを妨げるものがあるかどうかはわかりません。

一般に、Visual Studio (VS) はより高度であり、少なくとも私が見た VS のバージョンでは、Eclipse よりもパフォーマンスが大幅に優れています。Eclipse は、世の中で最も優れた Java アプリケーションの 1 つであり、大量の RAM を搭載した最近のマシンでも非常にうまく動作します。

Answer 2

良い、 フライ級 ワードプロセッサで使用するにはばかげたパターンです。IIRC では、各文字がオブジェクトとして参照されていました [注:それはそれぞれでした グリフ, OS が喜んでそれを描画してくれるので、これはまだクレイジーです]。ポインタが文字より幅が広く、すべての処理が間接演算に関連付けられているため、ワード プロセッサでその特定のパターンをそのように使用するのは気が狂いそうです。

ワード プロセッサの設計に興味がある場合は、パターンについては触れていないものの、いくつかのパターンについて説明している記事を見つけました。 ワードプロセッサ設計の基礎となるデータ構造と設計上の考慮事項.

デザインパターンはあなたの生活を楽にするためにあるのであって、あなたが純粋になるためではないということを覚えておいてください。パターンを使用するには理由があり、何らかの利点がなければなりません。

Answer 3

GoF とパターン一般のポイントは、物事を正しいものとして「正しく」行う方法について話すことであり、状況に応じて正しいものとして必ずしも「正しい」とは限りません。パフォーマンスが問題であり、適切なパフォーマンスを提供する名前付きパターンがないことがわかった場合は、おそらく独自の方法で進めることを正当化できるでしょう。しかし、パターンについて十分な知識があれば、「賢明なデフォルト」が得られ、適切なパフォーマンスを得るために必要な範囲でのみ明瞭さ、SoC などを犠牲にすることになるでしょう。

標準から「逸脱している」と感じると、a) よく考え、b) 慣用的ではないコードをよくコメントするようになります。

パターンは重要な知識ですが、福音となるものは何もなく、常に判断を下さなければなりません。

そうは言っても、パターンと最新の JDK を使用してまともなテキスト エディターを作成できない理由は思いつきません。

Answer 4

覚えておかなければならないことの 1 つは、GoF の本は 90 年代初頭に書かれたもので、当時は普及している OS に大規模なグラフィック ライブラリがなかったということです。当時はWindowsですらまだOSではありませんでした。

IIRC GoF は 1994 年にリリースされました。1994 年でも Windows 95 ベータ版は入手可能であり (私の 486DX33 上で実行されていました)、Windows 3.x はおよそ 1990 年から存在していました。

Answer 5

Eclipse + netbeans + IntelliJ はすべて、ほとんどすべて Java または 何か JVM (C++ ではなく) 上で実行されます。これらの IDE のうち少なくとも 2 つでは、私はエディター コードに時間を費やしたので、すべて Java であることを保証できます (そして、それも簡単ではありません)。

VS 2005 が私にとって Visual Studio を使った最後の経験でしたが、その時でさえ、Eclipse の方がはるかに応答性が高いと思っていました (ウォームアップとインデックス作成の時間を考慮すると、IntelliJ の方が二重に優れています)。

それがどのように関連しているかはわかりませんが、それが私の経験です。しかし、Visual Studio が今日でも C++ で書かれていることには驚きました。C# を使用することは Microsoft の利益になると思います。少なくとも、C# を使用するとパフォーマンスが大幅に向上するでしょう。自分で作ったドッグフードを食べるのとは違います。

Answer 6

はい、現在のマシンは十分な速度と十分なメモリを備えているため、それが可能です。Squeak を見ると、Smalltalk で書かれた Smalltalk IDE がわかります。これは Java よりもかなり遅いですが、それでも十分に高速です。一方、HD ビデオ編集には、現在、下位レベルのサポートが必要です。

Answer 7

この質問は実際には Java と Java に関するもののようです。C++ のパフォーマンス。それはオブジェクト指向ではなく、ガベージ コレクションなどを使用して仮想マシン上で実行されます。

このホワイトペーパー Java とC++ のパフォーマンスについては一読の価値があるかもしれません。