Автоматические свойства C# 3.0 - полезно или нет?

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

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

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

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

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

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

Мы постоянно используем их в Stack Overflow.

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

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

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

public string Name = "DefaultName";

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

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

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

У Ruby это всегда было:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Единственная проблема, с которой я сталкиваюсь, это то, что они не заходят достаточно далеко. В том же выпуске компилятора, в котором добавлены автоматические свойства, добавлены частичные методы. Почему они не соединили их вместе, мне непонятно. Простой "частичный OnИзмененный "сделал бы эти вещи действительно действительно полезными."

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

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

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"; }

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

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

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

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

• нужен доступ к полю извне его сборки, или
• нужно прикрепить логику к геттеру / сеттеру

Сделай это:

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

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

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

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

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

Сделать это:

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

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

Что ж, с фрагментами кода одноименное автоматическое свойство будет состоять всего из семи нажатий клавиш;)

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

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

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

Таким образом, это имеет преимущества перед простым автосвойством get / private set.

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

public string Title { get; }

или же

public string Title { get; private set; }

Это то, о чем вы говорите?

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

Так просто.

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

I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn't have been a class in the first place. It's just a data structure. And if it really is a data structure, make it a data structure.

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

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

В VS2008 отсутствует рефакторинг Расчленить авто-свойство.

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

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