22

オブジェクト初期化子がC＃に登場したとき、私は興奮しすぎました。

MyClass a = new MyClass();
a.Field1 = Value1;
a.Field2 = Value2;

短く書き直すことができます：

MyClass a = new MyClass { Field1 = Value1, Field2 = Value2 }

オブジェクト初期化コードはより明白ですが、プロパティ数が数十になり、割り当ての一部がnull許容値を処理する場合、「null参照エラー」がどこにあるかをデバッグするのは困難です。Studioは、オブジェクト初期化子全体をエラーポイントとして表示します。

最近は、エラーのないプロパティにのみオブジェクト初期化子を使用して簡単に割り当てています。

複雑な代入にオブジェクト初期化子をどのように使用しますか、それとも数十の代入を使用するのは悪い習慣ですか？

前もって感謝します！

4

3 に答える 3

18

さて、オブジェクト初期化子を使用する私の主な利点は、最初に可変型が必要なことです。可能な場合は、不変型を使用することを好みます。そうは言っても、オブジェクト初期化子が機能する場合（UIコントロールなど）、私はそれらを使用する傾向があります。

割り当ての値の計算が特に複雑である場合、私はおそらく2度考えます。特に、単一の式で値を取得できる必要があり、複数のステートメントで計算するよりも読みにくくなる可能性があります。 。しかし、これが最初から実行可能である状況では、これは比較的まれです。

オブジェクト初期化子を使用したプロパティの割り当て中に例外が発生したとは言えません。それは私が思いついたものではありません。もしそうなら、私はおそらくとにかく失敗した単体テストを書こうとします。その時点で、コードは通常、デバッガーなしで簡単に修正できます。

明らかに、モデレートは常に良いことです-これを極端にすることを提案しているわけではありません...しかし、ダースのプロパティを設定している場合、オブジェクト初期化子を使用することは、ダースのプロパティを持つことほど私には関係ありません最初に設定します。これらのダースのプロパティのいずれかが関連していますか？それらはどういうわけか一緒にカプセル化されるべきですか？（場合によっては、これも問題ありませんが、特にUIコントロールの場合は問題ありませんが、多くの場合、そうではありません。）

于 2010-06-18T07:49:30.443 に答える
3

アプリケーションをデバッグしている場合でも、ほとんどの場合、VSのデバッグツールを使用して、null参照の原因となっている割り当てを特定できるはずです。

ただし、割り当てを複数の行に分割すると、例外がスローされたときにVSが正しい行を指すようになると思います。

MyClass a = new MyClass {
                    Field1 = Value1,
                    Field2 = Value2 };

注：私は自分でこれを行うわけではないので、私の（おそらく）恐ろしい改行スタイルについては優しくしてください。

于 2010-06-18T07:50:22.703 に答える
0

ご指摘のとおり、デバッグが難しいため、開発中のコードでは使用しません。

十分にテストされたコードの場合、コードを読みやすくすることができますが、読みやすくするためだけに、十分にテストされて機能するコードをいじってはいけないと主張することもできます。

主にLinq構文を合法にするために、言語に導入されたオブジェクト初期化子を覚えておいてください。それはそれがもっと広く使われるべきだという意味ではありません。

そうは言っても、多数のコントロールに多数のプロパティを設定している場合は、インデントだけで、特定のコントロールにプロパティが設定されている場所の概要をすばやく簡単に把握できます。

于 2010-06-18T07:49:53.077 に答える