3

一部のファイルの分析および検証結果を表すライブラリにいくつかのクラスがあります。

これらのクラスには、列挙型、無効なプロパティのリストなどが含まれます。

ライブラリを使用する GUI アプリケーションを作成し、それらのクラスをリッチ テキスト ボックスに読み取り可能な形式で記述するための関数をいくつか作成しました。

クラスの ToString オーバーライドでこの書式設定を記述しなければならない場合があることに気付きました。

ただし、この書式設定はすべて非常に長く、タブと改行の挿入、リストの複数回の繰り返し、列挙型の説明の抽出などが含まれます。

だから私は疑問に思っていました-toStringのサイズと複雑さの標準は何ですか? toString に難しい書式を書くと思いますか? または、他の一般的なインターフェイスを提供する必要があるかもしれません-クラスのフォーマットされた印刷可能な出力用の一般的なインターフェイスはありますか? それとも、GUI アプリケーションで実行しますか?

ありがとう！

4

2 に答える 2

2

UI の書式設定のようなものは、UI ライブラリ以外のライブラリに焼き付けるべきではありません。

代わりに、UI に表示されることを期待してフォーマットを生成するために必要な複雑なコードを実行できるように、エンティティをフォーマットできる UI に依存しない一連のクラスを提供することができます。

これらは、次のような単純なインターフェースを使用できます。

public interface IEntityFormatter<T>
{
    string GetFormattedValue(T myEntity);
}

public class Customer
{
    public string FullName {get;set;}
}

public class CustomerFormatter : IEntityFormatter<Customer>
{
    public string GetFormattedValue(Customer myEntity)
    {
        return myEntity.FullName;
    }
}
于 2012-04-30T12:47:38.390 に答える
0

一般に、ToStringそれほど複雑にすべきではありません。そうしないと、デバッグが遅くなる可能性があります (デバッガーによって自動的に呼び出されることが多いことに注意してください)。独自のインターフェイスを追加すると、カスタマイズをさらに追加することもできます。一方、書式設定の設定が必要ない場合は、それToStringを実装するのに適した場所になる可能性があります。

于 2012-04-30T12:48:48.287 に答える