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

c# .net automatic-properties

44532 просмотра

18 ответа

121478 Репутация автора

Примечание: это было опубликовано, когда я начинал 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 ничего не делают. Но когда я действительно хочу реализовать некоторую логику получения / установки, я все равно должен использовать пару приват / публич.

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

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

Автор: Michael Stum Источник Размещён: 12.08.2008 11:06

Ответы (18)


28 плюса

37046 Репутация автора

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

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

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

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

Автор: Ray Размещён: 12.08.2008 11:13

45 плюса

59240 Репутация автора

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

  1. Вы не можете привязать данные к полю, тогда как вы можете к свойству
  2. Если вы начнете использовать поле, вы не сможете позже (легко) изменить его на свойство
  3. Есть некоторые атрибуты, которые вы можете добавить в свойство, которое нельзя добавить в поле
Автор: lomaxx Размещён: 12.08.2008 11:13

116 плюса

47233 Репутация автора

Решение

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

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

Автор: Jeff Atwood Размещён: 12.08.2008 11:13

5 плюса

88189 Репутация автора

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

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

public string Name = "DefaultName";

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

Автор: Orion Edwards Размещён: 12.08.2008 11:22

5 плюса

33754 Репутация автора

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

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

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

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter
Автор: Mike Stone Размещён: 13.08.2008 12:14

2 плюса

9027 Репутация автора

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

Автор: David Wengier Размещён: 13.08.2008 01:36

60 плюса

100243 Репутация автора

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

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

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

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

Автор: Keith Размещён: 13.08.2008 07:09

1 плюс

4733 Репутация автора

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

Автор: pbh101 Размещён: 17.08.2008 10:40

1 плюс

6473 Репутация автора

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

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

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

Сделай это:

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

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

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

Автор: ESV Размещён: 17.08.2008 11:19

8 плюса

11076 Репутация автора

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

Автор: ICR Размещён: 18.08.2008 12:27

0 плюса

17499 Репутация автора

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

Сделать это:

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

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

Автор: Brian Leahy Размещён: 21.08.2008 11:13

0 плюса

11076 Репутация автора

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

Автор: ICR Размещён: 26.08.2008 09:01

18 плюса

82758 Репутация автора

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

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

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

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

Автор: Domenic Размещён: 27.08.2008 06:04

0 плюса

12933 Репутация автора

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

public string Title { get; }

или же

public string Title { get; private set; }

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

Автор: Andrei Rînea Размещён: 30.08.2008 11:59

2 плюса

9534 Репутация автора

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

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

Автор: Omer van Kloeten Размещён: 07.09.2008 08:06

28 плюса

10964 Репутация автора

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

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

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

Автор: Giovanni Galbo Размещён: 08.10.2008 11:21

0 плюса

23364 Репутация автора

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

Что VS2008 отсутствует, так это рефактор Explode Auto-Property .

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

Автор: Johnno Nolan Размещён: 05.12.2008 10:24

12 плюса

432 Репутация автора

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

Автор: Theo Размещён: 05.12.2008 10:59
32x32