c# возражают сложности инициализатора. лучшая практика
Я был слишком взволнован, когда объектный инициализатор появился в C#.
MyClass a = new MyClass();
a.Field1 = Value1;
a.Field2 = Value2;
может быть переписан короче:
MyClass a = new MyClass { Field1 = Value1, Field2 = Value2 }
Объектный код инициализатора более очевиден, но когда число свойств достигает дюжины и некоторые соглашения о присвоении с nullable значениями, трудно отладить, где "ошибка нулевой ссылки". Studio показывает целый объектный инициализатор ошибочной точкой.
В наше время я использую объектный инициализатор для простого присвоения только для безошибочных свойств.
Как Вы используете объектный инициализатор для сложного присвоения, или это - плохая практика для использования дюжины присвоений вообще?
Заранее спасибо!
3 ответа
Моя основная проблема с инициализаторами объектов заключается в том, что они требуют наличия изменяемого типа для начала: там, где это возможно, я предпочитаю использовать неизменяемые типы. Сказав это, когда инициализатор объекта будет работать (например, для элементов управления пользовательского интерфейса), я предпочитаю их использовать.
Я бы подумал дважды, если бы значения для присваиваний были особенно сложными для вычисления - в частности, вы должны иметь возможность получить значение в одном выражении , и это может оказаться меньше читабельнее, чем вычисление по нескольким операторам ... но это относительно редко в ситуациях, когда это возможно для начала.
Я не могу сказать, что у меня были проблемы с исключениями во время присвоения свойств инициализаторам объектов - это просто не то, что мне приходит в голову. Если бы это было так, я бы, вероятно, все равно попытался написать неудачный модульный тест, и в этот момент код обычно легко исправить без отладчика.
Очевидно, что модерация - это всегда хорошо - я не предлагаю доводить это до крайности ... но если вы устанавливаете дюжину свойств, использование инициализатора объекта не будет для меня такой большой проблемой, как наличие дюжина свойств, которые нужно установить для начала. Связаны ли какие-либо из этих дюжин свойств? Должны ли они быть как-то инкапсулированы вместе? (В некоторых случаях подходит - опять же, особенно с элементами управления пользовательским интерфейсом - но часто это не так.)
Если вы отлаживаете свое приложение, в большинстве случаев вы все равно должны иметь возможность использовать инструменты отладки VS, чтобы определить, какое назначение вызывает нулевую ссылку.
Однако, если вы разделите назначение на несколько строк, я думаю, что VS будет указывать на правую строку при возникновении исключения:
MyClass a = new MyClass {
Field1 = Value1,
Field2 = Value2 };
Примечание: я не делаю этого сам, поэтому будьте осторожны с моими (возможно) ужасный ломающий линию стиль.
Я никогда не использую его в коде, который находится в разработке, потому что, как вы указываете, его труднее отлаживать.
Для хорошо протестированного кода это может сделать его более читаемым, хотя можно было бы возразить, что вы не должны возиться с хорошо протестированным и работающим кодом только для того, чтобы его было легче читать.
Помните, инициализаторы объектов были введены в язык в первую очередь для того, чтобы сделать синтаксис Linq законным. Это не означает, что его следует использовать более широко.
При этом, если вы устанавливаете набор свойств для нескольких элементов управления, один только отступ может значительно упростить получение быстрого обзора того, где определенные элементы управления имеют свои свойства.