7

問題は次のとおりです。

  • GUI ライブラリToStringは、クラスのデフォルト表現として使用するのが好きです。そこでローカライズする必要があります。
  • ToStringロギングに使用されます。そこでは、プログラミング関連の情報を提供する必要がありますが、翻訳されず、代理キーや列挙値などの内部状態が含まれます。
  • ToStringString.Formatストリームに書き込むときなど、オブジェクトを引数として受け取る多くの文字列操作で使用されます。コンテキストに応じて、異なるものを期待します。
  • ToString同じオブジェクトの多くの異なる表現がある場合、制限が多すぎます。ロングフォームとショートフォーム。

用途が異なるため、さまざまな種類の実装があります。そのため、信頼性が低すぎて実際には役に立ちません。

ToString有用であるためにはどのように実装する必要がありますか? いつ使用すべきToStringか、いつ使用を避けるべきか?

.NET Framework のドキュメントには次のように書かれています。

このメソッドは、カルチャに依存する人間が判読できる文字列を返します。

同様の質問がありますが、同じではありません。

4

5 に答える 5

5

小さな小さなメソッドに大きな期待を寄せているようです:)私の知る限り、クラスごとに動作が異なる可能性がある場合に、非常に多くの異なるコンテキストで一般的なメソッドを使用することはお勧めできません。

ここに私の提案があります：

1. GUI ライブラリにオブジェクトの ToString() を使用させないでください。代わりに、より意味のあるプロパティを使用します (ほとんどすべてのコントロールは、ToString 以外のプロパティを表示するようにカスタマイズできます)。たとえば、DisplayMember を使用します。2. オブジェクトに関する情報を取得するとき (ロギングまたはその他の使用法のために)、誰かに (別のオブジェクトまたはオブジェクト自体) 提供する必要があるものと表示する方法を決定させます (戦略パターンが役立つ場合があります)。

于 2009-09-10T09:31:59.380 に答える
2

System.Object.ToString() のオーバーライドと IFormattable の実装を説明する素晴らしい記事を次に示します。

于 2009-09-10T09:30:15.950 に答える
1

考慮すべきもう1つの問題は、ToStringとVisualStudioのデバッガーの緊密な統合です。ウォッチウィンドウには、ToStringの結果が式の値として表示されるため、メソッドが遅延読み込みを実行したり、副作用があったり、時間がかかったりすると、奇妙な動作が見られたり、デバッガーがハングしたように見えることがあります。 。確かに、これらの品質は、適切に設計されたToStringメソッドの特徴ではありませんが、発生します（たとえば、単純な「データベースから翻訳をフェッチする」実装）。

したがって、デフォルトのToStringメソッド（パラメーターなし）はVisual Studioのデバッグフックであると考えています。これは、デバッグコンテキストの外部でプログラムが使用するために、通常はオーバーロードしないようにする必要があることを意味します。

知識のある人はデバッグ属性（DebuggerTypeProxyAttribute、DebuggerDisplayAttribute、DebuggerBrowsableAttribute）を利用してデバッガーをカスタマイズしますが、多くの人（私を含む）は通常、ToStringによって生成され、ウォッチウィンドウに表示されるデフォルトの出力で十分だと考えています。

これはかなり厳密な観点であると理解しています-ToStringをデバッガーフックとして書き留めます-しかし、IFormattableを実装する方がより信頼性が高く拡張可能なルートのようです。

于 2009-09-15T19:34:19.200 に答える
1

それは、クラスの使用目的によって異なります。多くのクラスは、自然な文字列表現 (つまり Form オブジェクト) を持っていません。次に、デバッグ時に役立つ有益なメソッド (フォーム テキスト、サイズなど) として ToString を実装します。クラスがユーザーに情報を提供することを意図している場合は、値のデフォルト表現として ToString を実装します。たとえば、Vector オブジェクトがある場合、ToString はベクトルを X および Y 座標として返す場合があります。ここで、クラスを記述する他の方法がある場合は、代替メソッドも追加します。したがって、Vector については、説明を角度と長さとして返すメソッドを追加するかもしれません。

デバッグの目的で、DebuggerDisplay 属性をクラスに追加することもできます。これは、デバッガーでクラスを表示する方法を示していますが、文字列表現には影響しません。

文字列表現からオブジェクトを作成できるように、ToString によって返される値を解析可能にすることも検討してください。Int32.Parse メソッドでできるように。

于 2009-09-10T09:18:42.890 に答える
0

個人的には、ToString をそれほど頻繁に実装することはありません。多くの場合、型の主な役割はデータではなく動作を定義することであるため、あまり意味がありません。それ以外の場合は、クライアントがそれを必要としないため、単に問題ではありません。

いずれにせよ、それが理にかなっているいくつかのケースを次に示します (完全なリストではありません)。

  • ToString の結果を解析して、データを失うことなく型のインスタンスに戻すことが考えられる場合。
  • 型が単純な (つまり、複雑ではない) 値を持つ場合。
  • 型の主な目的がデータをテキストにフォーマットすることである場合。

リストされている使用シナリオの間に矛盾があることに同意しません。表示が主な目的の場合、ToString はユーザー フレンドリーなテキストを提供する必要がありますが、ログ記録 (または、あなたが説明したようにトレース) の場合は、UI 固有の要素をトレースするべきではありません。むしろ、詳細なトレース データを書き込むことを目的とするオブジェクトです。

したがって、単一責任の原則に従って同じ型であってはならないため、競合はありません。

さらに制御が必要な場合は、いつでも ToString メソッドをオーバーロードできることに注意してください。

于 2009-09-10T09:27:12.120 に答える