14

コード レビューで、同僚が私のコードを変更して、Stream をパラメーターとして渡すようにしました。彼は、これはオブジェクトを処分する責任が発信者に明確であることを保証するためであると述べました。ある意味共感できる。オブジェクトの作成者がクリーンアップも担当することをお勧めします。

一方、どちらの方法でも、usingこれ以上明確にする必要はありません。私は、より単純なメソッド呼び出しも好みます。

取った

    public static TextReader Serialize<T>(T obj) where T: new()
    {
        if (obj == null) throw new ArgumentNullException("obj");
        return Serialize<T>(obj, null);
    }

VS

    public static void Serialize<T>(T obj, TextWriter outbound) where T : new()
    {
        if (obj == null) throw new ArgumentNullException("obj");
        Serialize<T>(obj, outbound, null);
    }

追加のパラメーターを追加する技術的な理由はありますか?

4

4 に答える 4

9

それは、コード アーキテクチャに厳密に依存します。

私は、個人的には、関数の定義がストリームを閉じたり破棄したりしないと述べている2番目のアプローチが好きです（もう1つの引数を追加しても）が、それは呼び出し元次第です。

これは、同じストリームで同じ関数を呼び出す場合に非常に便利です。想像すると、すべての関数呼び出しがストリームを閉じて再度開くと、リソースを消費する操作になります。

于 2012-05-14T19:58:54.663 に答える
4

TextWriter が既に開いている可能性があります。そのため、私は 2 番目のバージョンを好みます。また、Serialize メソッドが行うことの範囲が縮小されます。シリアル化されますが、何も開かれません。オープニングは別の関心事です。

于 2012-05-14T19:59:06.223 に答える
1

プロジェクトが進化するにつれて、最初のアプローチでコードを維持しているプログラマーは、ストリームを閉じるのは呼び出し元のコードの責任であることを覚えていない可能性があります (特に重要な場合)。発信者は正しいことを行うためにドキュメントに依存する必要があり、誰もがドキュメントを読みますよね? ;)

2 番目のアプローチは、リソースの「バランス」を改善します。責任の分離がどこにあるのかがより明確になります。

于 2012-05-14T20:11:45.977 に答える
0

オーバーロードされた Serialize-T メソッドはストリームを作成しますか? その場合、「使用」がより簡単になるため、私は＃1を好みます。

using (var stream = Serialize(a_T)))
{
    // Do something else with the stream?
}

一方、呼び出し元がストリームを供給した方がよい場合もあります。その場合は、la オプション 2 で 1 つを渡します。

于 2012-05-14T20:01:37.857 に答える