41

私のプロジェクトのリード開発者は、プロジェクトのtoString（）実装を「純粋なくだらない」と呼んでおり、コードベースからそれらを削除しようとしています。

そうすることは、オブジェクトを表示したいクライアントは、オブジェクトを文字列に変換するために独自のコードを作成する必要があることを意味すると言いましたが、それは「はい」と答えました。

具体的には、このシステムのオブジェクトは長方形、円などのグラフィック要素であり、現在の表現はx、y、スケール、境界などを表示することです。

それで、群衆はどこにありますか？

toStringを実装する必要があるのはいつですか。

4

24 に答える 24

68

彼らはどのような害を及ぼしますか？それらを持っている場合、なぜそれらを削除するのですか? toString() は、デバッグ ステートメントを発行するときに非常に便利です。

個人的には、実行可能な toString() メソッドを使用する側で常に誤りを犯します。書く作業はほとんどありません。

于 2009-07-21T19:29:50.360 に答える
35

適切に作成された (または半分ほど適切に作成された) toString() メソッドを削除することは、純粋な狂気です。はい、私はこれらを書くのが面倒であることがよくあります (オブジェクトが最終的に使用されない場合が多いため) が、持っていると非常に便利です。

これらを取り除きたい正当な理由が本当に思い浮かびません。

于 2009-07-21T19:31:17.690 に答える
18

クラスがtoStringを実装していることを常に確認してきました。

デバッグ中にクラスの現在の状態をデバッグする簡単な方法を提供し、エラーをログに記録しているときは、それをログ メッセージに含めることができます。

于 2009-07-21T19:30:32.153 に答える
15

私はtoString()実装を保持します。デバッグに関しては非常に貴重であり、グラフィカル コンポーネントの適切な代替テキストを作成できます。

于 2009-07-21T19:31:44.820 に答える
12

私は逆に toString() を慎重にオーバーライドする必要があると主張します。デフォルトの toString() 実装は非常に情報が少なく、基本的に役に立ちません。優れた toString() 実装により、開発者はオブジェクトの内容を一目で確認できる非常に便利なビューを得ることができます。そこにすべてを入れる必要はないかもしれませんが、少なくとも重要なものは入れてください。主任開発者は、「粗雑さ」を心配するのではなく、実際にコーディングして機能を追加する必要があると思います。

于 2009-07-21T19:45:58.130 に答える
11

クライアントコードがオブジェクトの状態の詳細を気にせず、状態ごとに何が起こっているのかを要約した、より人間が理解できるセンスメイキングのメッセージを気にする、より複雑なオブジェクトにのみ実装します。 。

JavaBeansのような他のすべての場合、低レベルのデバッグを行う必要がある場合は、クライアントコードがオブジェクトをToStringBuilderメソッドなどにスローすることを期待します。

ToStringBuilder.reflectionToString(myObject);

または、クライアントコードは、標準のプロパティゲッターを呼び出して、好きなようにログに記録する必要があります...

于 2009-07-21T19:36:57.087 に答える
7

一般的に、toString()良いものです。特に、デバッグには非常に便利です。

実装には、コストとリスクtoString()がないわけではありません。すべてのコードと同様に、実装は残りのコードで維持する必要があります。これは、クラス フィールドとの同期を維持することを意味します。たとえば、フィールドが追加または削除された場合は、適切に更新する必要があります (や などのメソッドについては、既にこれを行っているはずです)。toString()toString()toString()hashCode()equals()

導入にtoString()はリスクも伴います。たとえば、システム内の 2 つのクラスが他方のインスタンスへの参照 (双方向リンク) を持っているとします。この場合、各toString()クラスtoString()の実装toString()が他のクラス。

toString()あなたのシステムに同期していないメソッドや、スタック オーバーフローなどのバグを引き起こすメソッドが大量にある場合、あなたの同僚には合理的な理由があるかもしれません。そのような場合でも、バグのあるメソッドをコメントアウトtoString()してコードに残すだけです。各toString()メソッドは、将来必要に応じてコメントを外して個別に更新できます。

于 2009-07-21T20:55:49.890 に答える
6

私は常に、すべての 、 、および/または永続データを保持するオブジェクトに対してtoString() メソッドを自動生成します。プライベートな内部プロパティについては、適切なログ記録の実践がうまくいくはずです。POJODTO

toString メソッドのパスワードやその他の重要な情報を[Omitted](または極秘の性質に類似したもの)に置き換えることを常に忘れないでください。

于 2011-03-17T00:05:43.117 に答える
4

まあ、彼は物事を踏みにじる。

toString（）があまりにも便利だとは言えません。プレゼンテーションには、他のツールが必要になります。

ただし、コレクションの内容を確認できるため、toString（）はデバッグに非常に役立ちます。

すでに書かれているのになぜ削除するのかわかりません

于 2009-07-21T19:33:56.313 に答える
4

答えは、toString() メソッドの複雑さ、維持に必要な作業量、使用頻度によって異なると思います。ロギングとデバッグに toString() を頻繁に使用すると仮定すると、これらのメソッドを削除してもあまり意味がありません。しかし、めったに使用されず、コード内で何かが変更されるたびに多くの作業を維持する必要がある場合は、 toString() メソッドのすべてまたは一部を削除するための有効な議論がある可能性があります。

これらのオブジェクトを表示する必要があるクライアントについて言及しました。このことから、あなたのコードには、他の開発者が使用するある種のライブラリまたは API が含まれているか、含まれていると思います。この場合、有用な toString() 実装を維持することを強くお勧めします。ロギングやデバッグをあまり行わない場合でも、クライアントは、自分で作成および保守する必要のない便利な toString() メソッドがあることを高く評価する場合があります。

于 2009-07-21T19:41:01.727 に答える
3

+1マイクC

toString（）は、デバッグの有用性に加えて、インスタンスのクラス作成者の視点を理解するための非常に貴重なツールです。

FWIW、toStringの出力が期待するものと異なる場合（提供仕様ドキュメント）、何かが深刻な問題を抱えていることがすぐにわかります。

于 2009-07-21T20:01:07.053 に答える
2

オブジェクトを文字列表現として（ログ、コンソール、またはある種の表示ツリーのいずれかで）表示するために、それが予想されるユースケースまたは要件である場合は、toStringを実装する必要があると思います。

そうでなければ、私は開発者に同意します-何かを変更するたびに、toStringが壊れることがあります。nullなどに注意する必要があるかもしれません。

ただし、実際にはデバッグやロギングで使用されることが多いため、これらを完全に除外する必要があるかどうかは明らかではありません。

私はjsightに同意します。それらがすでに書かれていて、きちんと書かれている場合は、少なくとも邪魔になるまで（実際にクラスにフィールドを追加するなど）、そのままにしておきます。

于 2009-07-21T19:33:27.000 に答える
2

toStringsに表示される情報が少なすぎる、または多すぎるという問題が常に発生するため、これは理にかなっています。

代わりに、Jakarta Commons LangでToStringBuilderを使用することは、チームにとって理にかなっている場合があります。

System.out.println("An object: " + ToStringBuilder.reflectionToString(anObject));

オブジェクトをイントロスペクトし、パブリックフィールドを出力します。

http://commons.apache.org/lang/api-2.3/org/apache/commons/lang/builder/ToStringBuilder.html

于 2009-07-21T21:40:28.570 に答える
2

個人的には、JList、JTable、または toString() を使用するその他の構造でオブジェクトを使用するとき、またはデバッグするときにそれらを実装します (はい、Eclipse にはデバッグ フォーマッタがありますが、toString() の方が簡単です)。

おそらく、多くの JDK クラスが toString() を持っていることに反論することができます。それらも削除する必要がありますか？;)

于 2009-07-21T19:31:39.123 に答える
2

デバッグの目的では、誰にも勝るものはありませんtoString。デバッガーと単純なデバッグ出力の両方で実用的です。equalsそれらもオーバーライドする場合は、およびhashCodeメソッドが基づいているすべてのフィールドが表示されることを確認してください!

ただし、エンドユーザーへの表示には使用toStringしません。そのためには、適切なフォーマットを行う別のメソッドを作成し、必要に応じて i18n を作成する方がよいと思います。

于 2009-07-21T19:45:54.197 に答える
2

そうすることは、オブジェクトを表示したいクライアントがオブジェクトを文字列に変換するために独自のコードを書かなければならないことを意味すると言いましたが、それは「はい、そうするでしょう」と答えました。

これは単独で答えられる質問ではありません... クライアント (またはそれを書いている人) に、そのアイデアについてどう思うか尋ねるべきです。私が Java ライブラリを使用していて、デバッグのためにその toString() オーバーロードに依存している場合、ライブラリの開発者がそれらをパージすることを決定した場合、私はかなりイライラするでしょう。

于 2009-07-21T23:31:36.583 に答える
2

公平を期すために、ここで開発者は言いましたが、いかなる意味でもリード開発者ではありません。

元の問題は、必ずしも toString() に関するものではありませんが、2 つ目のメソッド paramString に関するものです。

http://code.google.com/p/piccolo2d/issues/detail?id=99を参照してください。

于 2009-07-21T23:34:00.930 に答える
2

既存のtoString()実装に問題がある場合、開発者は問題を修正する必要があります。現在の実装はすべて「粗雑」であり、それらを削除することは、既存のtoString()メソッドが異常に不十分に記述されていない限り、積極的に害を及ぼしていると述べています。

開発者が機能しているメソッドを削除しないよう強くお勧めします。toString()

于 2009-07-22T22:49:42.783 に答える
2

特にデバッグ目的のために、 toString() 実装を確実に保持します。主に C++ の開発者として、この点で Java と同じように C++ が簡単であることを願っています (演算子のオーバーロードは苦痛になる可能性があります)。

于 2009-07-22T01:43:12.220 に答える
1

常に実装する:)上記のように、デバッグには非常に役立ちます。

于 2009-07-21T19:34:15.703 に答える
1

デバッグ目的に適しています。ただし、特定のオブジェクトを文字列としてエンド ユーザーに表示する場合は、 toString() 実装を使用しないで、そのためのカスタム メソッドを提供する必要があります。

だからに関して

そうすることは、オブジェクトを表示したいクライアントがオブジェクトを文字列に変換するために独自のコードを書かなければならないことを意味すると言いましたが、それは「はい、そうするでしょう」と答えました。

あなたのチームリーダーに同意します。オブジェクトを任意のクライアントに表示する場合は、カスタム実装を使用します。デバッグ目的で使用する場合は、toString() を使用します。

于 2009-07-22T12:50:12.960 に答える
-1

toString（）メソッドの1つからConcurrentModificationExceptionがスローされるため、時折欠点があります。もちろん、同期させないのは私たち自身の責任です。

于 2009-07-21T23:51:59.473 に答える