0

私は最近、次のことを考えました。オブジェクトを定義してtoStringメソッドをオーバーライドすると、プログラムの実行中に複数回呼び出される可能性があります。特定のUIコンポーネントがどのように更新されるか（更新時にJTableが各セルメンバーのtoStringメソッドを呼び出すか）、またはオブジェクトを変更する命令を踏むたびにデバッガーがtoStringを呼び出すかどうかなどはわかりません。とにかく、そうなるかどうかを考えていました。構造がIMMUTABLEの場合、遅延評価されたStringをtoString定義として定義することは有益です。

private String toString;
//.. definitions of many components, sets, lists which won't change

public String toString(){
   if (toString == null) // instantiate
   return toString;
}

上記は行う価値がありますか？

4

3 に答える 3

2

文字列の作成プロセスが長く、作成した文字列を頻繁に使用する場合は、保存する必要があります。そうでない場合は、メソッドを呼び出す回数によって異なりますtoString()(メモリと CPU 時間の間の常に同じ古い戦争)。

クラスが不変で、toString()メソッドが少なくとも 1 回呼び出されることがわかっている場合は、常にチェックするのではなく、コンストラクター (またはファクトリ) で文字列をインスタンス化する必要があります。

于 2012-10-19T10:24:51.943 に答える
0

Java の文字列リテラル プールにより、これについて心配する必要はありません。多くの一意の文字列を作成していないと仮定すると、Java はクラス ファイルのロード時または初期化時にコードを走査し、文字列を見つけて文字列リテラル プールに追加します。

これは素晴らしい記事であり、素敵な図を使った概要です -文字列リテラルプールの概要

他の提案は、独立した部分が出力文字列のみのバッファに追加されないため、StringBuffers を使用することです。

StringBuffer を static にすると、毎回新しいオブジェクトを作成することも回避できますが、実際には toString() を呼び出す頻度に依存します。

これが本当にボトルネックである場合、Tom Johnson が提案したように、プロファイラーを実行することが次の方向性になるでしょう。

于 2012-10-19T11:00:10.560 に答える
0

ここで、最適化の標準ルールが機能します。

  1. やらないでください。
  2. (専門家のみ) まだ実行しないでください。少なくとも、解決が必要な問題である理由を示すプロファイリング情報を取得するまでは実行しないでください。

パフォーマンス上の理由で明快さと保守性が失われているため、それらのパフォーマンス上の理由と、コストに見合う価値があるかどうかを定量化してください。

于 2012-10-19T10:30:21.573 に答える