c # сложность инициализатора объекта.лучшая практика - PullRequest
Новая
       1

c # сложность инициализатора объекта.лучшая практика

22 голосов
/ 18 июня 2010

Я был слишком взволнован, когда инициализатор объекта появился в C #. 

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

можно переписать короче: 

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

Код инициализатора объекта более очевиден, но когда число свойств достигает десятка, и некоторые из присваиваний имеют дело со значениями, допускающими обнуляемость, трудно отлаживать, где есть «ошибка нулевой ссылки». Studio показывает весь инициализатор объекта как точку ошибки.

В настоящее время я использую инициализатор объекта для прямого назначения только для безошибочных свойств.

Как вы используете инициализатор объекта для сложного присваивания, или вообще не рекомендуется использовать дюжину назначений?

Заранее спасибо!

Ответы [ 3 ]

18 голосов
/ 18 июня 2010

Что ж, моя главная проблема с инициализаторами объектов заключается в том, что для них требуется изменяемый тип: по возможности я предпочитаю использовать неизменяемые типы.Сказав это, когда инициализатор объекта будет работать (например, для элементов управления пользовательского интерфейса), я склонен использовать их.

Я бы мог подумать дважды, если значения для назначений были особенно сложны для вычисления- в частности, вы должны иметь возможность получить значение в одном выражении , и это может оказаться менее читабельным, чем вычисление его по нескольким операторам ... но это относительноредко в ситуациях, когда это возможно начать с.

Я не могу сказать, что у меня были какие-либо проблемы с исключениями во время присваивания свойств с инициализаторами объектов - это просто не то, что подходит мне.Если бы это было так, я бы, вероятно, попытался написать неудачный модульный тест в любом случае, и в этот момент код, как правило, легко исправить без отладчика.

Очевидно, что модерация всегда хорошая вещь - я не предлагаюдоводя это до крайности ... но если вы устанавливаете дюжину свойств, использование инициализатора объекта не будет для меня такой же проблемой, как наличие дюжины свойств для установки.Связаны ли какие-либо из этих дюжин свойств?Должны ли они быть как-то объединены?(В некоторых случаях хорошо - опять же, особенно с элементами управления пользовательским интерфейсом - но часто это не так.)

3 голосов
/ 18 июня 2010

Если вы отлаживаете свое приложение, то в большинстве случаев вы все равно сможете использовать средства отладки VS, чтобы определить, какое назначение вызывает пустую ссылку.

Однако, если вы разделите назначение по несколькимлинии, я думаю, VS будет указывать на правую линию, когда выдается исключение: 

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

Примечание: я не делаю этого сам, так что будьте осторожны с моим (возможно) ужасным переводом строки.

0 голосов
/ 18 июня 2010

Я никогда не использую его в коде, который находится в разработке, потому что, как вы указываете, его сложнее отлаживать.

Для хорошо протестированного кода это может сделать код более читабельным, хотя можно утверждать, что вам не следует возиться с хорошо протестированным и рабочим кодом просто для облегчения чтения.1004 * Помните, инициализаторы объектов были введены в язык прежде всего для того, чтобы сделать синтаксис Linq легальным.Это не значит, что его следует использовать более широко.

Сказав, что, если вы устанавливаете набор свойств для нескольких элементов управления, только отступ позволяет значительно быстрее получить представление о том, где определенные элементы управления имеют свои свойства.

...