Авто-свойства C # 3.0 - полезно или нет? [закрыто]

Примечание: это было опубликовано, когда я начинал C #. Обладая знаниями 2014 года, я могу с уверенностью сказать, что авто-свойства являются одними из лучших вещей, которые когда-либо случались с языком C #.

Я привык создавать свои свойства в C #, используя закрытое и открытое поле:

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Теперь, с .NET 3.0, мы получили авто-свойства:

public string Title { get; set; }

Я знаю, что это скорее философский / субъективный вопрос, но есть ли причина использовать эти авто-свойства, кроме как сохранить пять строк кода для каждого поля? Моя личная неприятность заключается в том, что эти свойства скрывают от меня вещи, и я не большой поклонник черной магии.

На самом деле скрытое приватное поле даже не отображается в отладчике, что нормально, учитывая тот факт, что функции get / set ничего не делают. Но когда я хочу реализовать некоторую логику получения / установки, я все равно должен использовать пару приват / публич.

Я вижу преимущество в том, что я сохраняю много кода (одна против шести строк), не теряя возможности изменить логику получения / установки позже, но опять же я уже могу это сделать, просто объявив открытое поле «Публичная строка заголовка» без необходимость {получить; устанавливать; } блок, таким образом, даже сохраняя больше кода.

Итак, что мне здесь не хватает? Почему кто-то на самом деле хочет использовать авто-свойства?

Мы используем их все время в переполнении стека.

Вы также можете быть заинтересованы в обсуждении свойств и общедоступных переменных . ИМХО, это действительно то, на что это реакция, и для этой цели это здорово.

Да, он просто сохраняет код. Это намного легче читать, когда у вас их много. Их быстрее написать и легче поддерживать. Сохранение кода всегда хорошая цель.

Вы можете установить разные области:

public string PropertyName { get; private set; }

Так что свойство может быть изменено только внутри класса. Это на самом деле не является неизменным, так как вы все еще можете получить доступ к приватному сеттеру через рефлексию.

Начиная с C # 6 вы также можете создавать истинные readonlyсвойства - то есть неизменяемые свойства, которые нельзя изменить вне конструктора:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

Во время компиляции это станет:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

В неизменяемых классах с большим количеством членов это экономит много лишнего кода.

Три больших недостатка использования полей вместо свойств:

1. Вы не можете привязать данные к полю, тогда как вы можете к свойству
2. Если вы начинаете использовать поле, вы не можете позже (легко) изменить его на свойство
3. Есть некоторые атрибуты, которые вы можете добавить в свойство, которое нельзя добавить в поле

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

Как вы сказали, вы можете использовать поля, и если вы захотите добавить логику к ним позже, вы конвертируете их в свойства. Но это может создать проблемы с любым использованием отражения (и, возможно, в другом месте?).

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

Я думаю, это то же самое, что и ключевое слово var. Вопрос личных предпочтений.

От Бьярне Страуструпа, создателя C ++:

Мне особенно не нравятся классы с большим количеством функций get и set. Это часто указывает на то, что это не должен был быть класс в первую очередь. Это просто структура данных. И если это действительно структура данных, сделайте ее структурой данных.

И знаешь, что? Он прав. Как часто вы просто оборачиваете приватные поля в get и set, фактически ничего не делая внутри get / set, просто потому, что это «объектно-ориентированная» вещь, которую нужно сделать. Это решение Microsoft от проблемы; это в основном публичные поля, которые вы можете связать.

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

private readonly string title;
public string Title
{
    get { return this.title; }
}

(где поле инициализируется в конструкторе с помощью переданного параметра, а затем доступно только для чтения.)

Так что это имеет преимущества перед простым get/ private setautoproperty.

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

Авто-свойства - такая же черная магия, как и все остальное в C #. Когда вы думаете об этом с точки зрения компиляции в IL, а не вначале для расширения до обычного свойства C #, это становится намного менее черной магией, чем многие другие языковые конструкции.

Я использую авто-свойства все время. До C # 3 я не мог возиться со всей типизацией и просто использовал вместо этого публичные переменные.

Единственное, чего мне не хватает, так это возможности:

public string Name = "DefaultName";

Вы должны перенести значения по умолчанию в ваши конструкторы со свойствами. нудно :-(

Я думаю, что любая конструкция, которая интуитивно понятна и сокращает количество строк кода, является большим плюсом.

Именно такие особенности делают такие языки, как Ruby, такими мощными (это и динамические функции, которые также помогают уменьшить избыточный код).

У Руби все это время было:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Единственная проблема, которую я имею с ними, состоит в том, что они не зашли достаточно далеко. В том же выпуске компилятора, в котором добавлены автоматические свойства, добавлены частичные методы. Почему они не соединили их, мне не под силу. Простое «частичное On <PropertyName> Changed» сделало бы эти вещи действительно очень полезными.

Это просто, это коротко, и если вы хотите создать реальную реализацию внутри тела свойства где-то вниз по линии, это не нарушит внешний интерфейс вашего типа.

Так просто, как, что.

Здесь следует отметить, что, насколько я понимаю, это всего лишь синтаксический сахар на стороне C # 3.0, означающий, что IL, сгенерированный компилятором, одинаков. Я согласен с тем, чтобы избегать черной магии, но, тем не менее, меньшее количество строк для одной и той же вещи, как правило, хорошо.

На мой взгляд, вы всегда должны использовать авто-свойства вместо открытых полей. Тем не менее, вот компромисс:

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

• нужен доступ к полю снаружи его сборки, или
• необходимо прикрепить логику к получателю / установщику

Сделай это:

1. переименовать поле
2. сделать это частным
3. добавить публичную собственность

Ваш код клиента не нужно будет менять.

Но когда-нибудь ваша система вырастет, и вы разложите ее на отдельные сборки и несколько решений. Когда это произойдет, любые открытые поля снова будут преследовать вас, потому что, как упоминал Джефф, изменение открытого поля на публичное свойство является критическим изменением API .

Я использую CodeRush, это быстрее, чем авто-свойства.

Сделать это:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Требуется всего восемь нажатий клавиш.

Хорошо с фрагментами кода, авто-свойство с тем же именем будет в общей сложности семь нажатий клавиш;)

@ Domenic: я не понимаю .. ты не можешь сделать это с авто-свойствами ?:

public string Title { get; }

или

public string Title { get; private set; }

Это то, что вы имеете в виду?

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

Чего не хватает VS2008, так это рефактора взрыва Auto-Property .

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