Почему автоматические свойства C# не поддерживают значения по умолчанию как 2010 VB?
Смотря на новые функции VB 2010, я наткнулся на поддержку Автореализованных Свойств.
Так как я работаю с C#, это казалось довольно знакомым, но я заметил, что VB действительно добавлял опцию, которую я хотел бы иметь в C#: установка произвольного значения по умолчанию для автореализованного свойства:
Public Class Person
Property Name As String = "Scott Guthrie"
Property Age as Integer = 35
End Class
Мне действительно нравится чистое использование автосвойств в C#. Это сохранило бы нас усилие по представлению отступающего поля и сцеплению его до свойства каждый раз, когда нам просто нужно значение по умолчанию, таким образом, загромождая код излишне.
Я задавался вопросом, почему это не было представлено в C# также? Каково могло быть объяснение для того, чтобы не сделать это? Обсуждение синтаксиса продолжается или является там техническими ограничениями к реализации этого?
4 ответа
А как насчет:
public class Person
{
public Person()
{
this.Name = "Scott Guthrie";
this.Age = 35;
}
public string Name { get; set; }
public string Age { get; set; }
}
на практике это сводится к тому же, и я полагаю, что это не такая уж большая дополнительная работа. Но, возможно, какое-то время VB выглядит яснее, чем C # ...; -)
РЕДАКТИРОВАТЬ (обоснование):
Вы просили обоснование в своем последнем комментарии под (и в) исходном вопросе . Размышляя вслух, я думаю, что принцип C #, согласно которому код инициализации идет в одно место и только в одно место, а именно в конструктор, является причиной этого решения. Добавление еще одного места, где вы должны искать код инициализации, усложняет отладку и делает код менее понятным.
Очевидно, что значение встроенной инициализации не может содержать другие инициализации или вычисления (по крайней мере, очень ограниченные).Хотя я согласен с тем, что на языке VB это может быть более лаконично, я бы понял команду C # и Андерса Хейлсберга, если бы они сказали, что они считают большим преимуществом наличие одного места для инициализации.
РЕДАКТИРОВАТЬ: вот что говорит об этом Microsoft . Короче говоря, не для C # 4.0, а, может быть, для C # 5.0? Также:
"Это не так просто, как кажется: следующее, что вам нужно, это чтобы конструктор инициализировал поле поддержки , но он может только сделайте это через установщик, который может быть не тем , который вам нужен. "
и (просто комментатор):
" Отсутствие инициализации или контроля конструктора делает эту функцию практически бесполезной для свойств, возвращающих ссылочный тип . "
Почему бы просто не использовать их по умолчанию в конструкторе? Это то, для чего это тоже.
Хотя я не Microsoft, я бы предположил, что предполагаемая выгода была меньше, чем затраты на реализацию, тестирование и поддержку этой функции.
Конечно, вы можете просто установить значения по умолчанию, объявив конструктор, но я согласен, что синтаксис VB немного понятнее (особенно если вы собираетесь украсить его метаданными, такими как
У меня есть решение для утомительного бизнеса по преобразованию авто-собственности в a property-with-backing-field: Моя надстройка, AtomineerUtils выполнит этот рефакторинг за вас одним нажатием клавиши.