Зачем вообще использовать поля вместо свойств?

Обычно свойствам требуется вспомогательное поле, если они не являются простыми «автоматическими свойствами» получателя / установщика.

Итак, если вы просто делаете ...

public string Name { get; set; } // automatic property

... вам не нужно поле, и я согласен, нет причин его иметь.

Однако, если вы делаете ...

public string Name
{
    get { return _name; }
    set 
    {
       if (value = _name) return;
       _name = value;
       OnPropertyChange("Name");
    }
}

... вам нужно это _name вспомогательное поле.

Для частных переменных, которые не требуют какой-либо специальной логики получения / установки, это на самом деле вызов суждения, делать ли частное автоматическое свойство или просто поле. Обычно я делаю поле, а затем, если мне нужно, чтобы оно было protected или public, я изменяю его на автоматическое свойство.

Обновить

Как заметил Ясир, если вы используете автоматические свойства, за кадром все еще скрывается поле, просто это не то, что вам действительно нужно печатать. Итак, суть в следующем: свойства не хранят данные, они предоставляют доступ к данным. Поля - это то, что на самом деле хранит данные. Значит, они вам нужны, даже если вы их не видите.

Обновление 2

Что касается вашего измененного вопроса ...

бывает ли когда-нибудь SomeType someField; предпочтительнее SomeType SomeProperty { get; set; }?

... одна вещь, которая приходит на ум: если у вас есть частное поле и (согласно соглашению для частных полей) вы называете его _name, это сигнализирует вам и всем, кто читает ваш код, что вы работаете напрямую с личными данными. Если, с другой стороны, вы сделаете все свойством и (в соответствии с соглашением о свойствах) вызовете свое частное свойство Name, теперь вы не сможете просто посмотреть на переменную и сказать, что это частные данные. Таким образом, использование только свойств удаляет некоторую информацию. Я не пробовал работать со всеми свойствами, чтобы определить, является ли это важной информацией, но что-то определенно потеряно.

Еще одна вещь, менее важная, - это то, что public string Name { get; set; } требует большего набора текста (и немного сложнее), чем private string _name.

Просто попробуйте использовать свойство при использовании аргументов ref / out:

someObject.SomeMethod(ref otherObject.SomeProperty);

Он не компилируется.

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

Предотвращение чрезмерного использования средств получения и установки собственности

Большинство людей не понимают, что средства получения и установки свойств похожи на методы, когда дело касается накладных расходов; в основном их отличает синтаксис. Невиртуальное средство получения или установки свойства, которое не содержит никаких инструкций, кроме доступа к полю, будет встроено компилятором, но во многих других случаях это невозможно. Вы должны внимательно относиться к использованию свойств; изнутри класса обращайтесь к полям напрямую (если возможно) и никогда не вызывайте свойства вслепую повторно без сохранения значения в переменной. Все это не означает, что вы должны использовать общедоступные поля!

Источник: http://dotnet.sys-con.com/node/46342

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

Я делаю это довольно часто.

Надуманный пример:

class Rectangle
{
   private readonly int _width;
   private readonly int _height;

   public Rectangle(int width, int height)
   {
      _width = width;
      _height = height;
   }

   public int Width { get { return _width; } }
   public int Height { get { return _height; } }
}

Это означает, что ничто внутри Rectangle не может изменить ширину или высоту после построения. Если кто-то попытается, компилятор пожалуется.

Если бы я вместо этого использовал автоматическое свойство с частным сеттером, компилятор не защитил бы меня от меня самого.

Еще одна причина, по которой я вижу, заключается в том, что если часть данных не должна быть раскрыта (оставайтесь private), зачем делать ее собственностью?

Хотя я согласен с тем, что я воспринимаю как «намерение» в заявлении Дэвида Басараба: «Нет причин публично раскрывать поля», я хотел бы добавить немного другой акцент:

Я бы изменил приведенную выше цитату Дэвида следующим образом: «Нет причин открывать публично поля ... вне класса ... кроме как посредством сознательного выбора инкапсуляции полей в свойствах, через которые строго контролируется доступ.

Свойства - это не просто «оболочка» синтаксиса над полями, «наклеенными на» C #: они являются фундаментальной функцией языка, разработанной по уважительным причинам, в том числе:

1. контроль того, что отображается и не отображается вне классов (инкапсуляция, скрытие данных)

2. разрешение выполнения определенных действий при доступе к свойству или его установке: действия, которые лучше всего выражаются в свойствах get and 'set, а не «повышаются» до методов, определенных извне.

3. Интерфейсы по дизайну не могут определять поля: но могут определять свойства.

Хороший объектно-ориентированный дизайн означает осознанный выбор «состояния»:

1. поля локальных переменных: какое состояние является частным для метода и переходным: локальные переменные, как правило, действительны только в рамках тела метода или даже со столь же "узким сроком службы", как в рамках чего-то вроде цикл for. Конечно, вы также можете рассматривать переменные параметров в методе как «локальные».

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

3. статические поля экземпляра: какое состояние будет свойством только класса, независимо от количества экземпляров класса.

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

   а. через общедоступные свойства: все аспекты этого хорошо освещены во всех других ответах здесь

   б. через индексаторы

   c. через методы

   d. общедоступные статические переменные обычно находятся в служебных классах, которые часто являются статическими.

Предлагаем вам обзор: MSDN на 'Полях .. . MSDN в свойствах ... MSDN в индексаторах

Я не понимаю, зачем вам использовать частные автосвойства. В чем преимущество

private int Count {get; set;}

над

private int count

Нет причин для публикации полей нет.

Если вы публикуете поле, вы не можете изменить источник информации, от встроенного определения до файла конфигурации без рефакторинга. \

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

Поля - единственное место, где вы можете хранить состояние. На самом деле свойства - это всего лишь пара методов со специальным синтаксисом, который позволяет отображать их в метод get или set в зависимости от того, как они используются: если свойство изменяет состояние или обращается к нему, это состояние все равно должно быть сохранено в поле. .

Вы не всегда видите поля. С автоматическими свойствами C # 3 поле создается для вас компилятором. Но он все еще там. Кроме того, автоматические свойства имеют некоторые существенные ограничения (например, отсутствие поддержки INotifyPropertyChanged, отсутствие бизнес-логики в установщиках), что означает, что они часто неуместны, и вам в любом случае необходимо создать явное поле и свойство, определяемое вручную.

Согласно ответ Дэвида, вы правы, если вы говорите об API: вы почти никогда не хотите, чтобы внутреннее состояние (поля) было частью API.

Синтаксис для полей писать намного быстрее, чем для свойств, поэтому, когда безопасно использовать поле (частное для класса), почему бы не использовать его и не сохранить лишнюю типизацию? Если бы автоматически реализованные свойства имели приятный короткий сжатый синтаксис и вам приходилось проделывать дополнительную работу, чтобы создать простое старое поле, люди могли бы просто вместо этого начать использовать свойства. Кроме того, теперь это соглашение на C #. Так думают люди, и это то, что они ожидают увидеть в коде. Если вы сделаете что-то отличное от обычного, вы запутаете всех.

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

Есть очень простая причина, по которой нам все еще нужны явные поля:

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

Я также подозреваю, что это влияет на производительность, но, возможно, это можно решить с помощью джиттера.

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

Поля и свойства не взаимозаменяемы. Я предполагаю, что вы имеете в виду доступ к частным полям через частные свойства. Я делаю это, когда это имеет смысл, но по большей части в этом нет необходимости. Оптимизатор JIT в любом случае будет встраивать доступ к частному полю через частное свойство. И перенос частного поля в частное свойство в любом случае не считается критическим изменением, поскольку частные члены не являются частью вашего интерфейса.

Лично я бы никогда не раскрывал какие-либо защищенные / общедоступные поля экземпляра. Тем не менее, как правило, допустимо предоставлять общедоступное статическое поле с модификатором readonly, если тип поля сам по себе является неизменяемым. Это часто наблюдается со статическими полями SomeStruct.Empty.

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

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

Скорость. Если поле устанавливается или считывается миллиарды раз в ходе моделирования, тогда вы хотите использовать поле, а не свойство, чтобы избежать накладных расходов или вызова подпрограммы. В соответствии с OO (DDD?), Насколько это возможно, в этих случаях я бы рекомендовал прибегать к полям только в классе, предназначенном для представления какой-то «ценности», такой как человек. Логика должна быть сведена к минимуму. Лучше иметь человека-создателя или человека-обслуживающего персонала.

Но если у вас есть эти проблемы, то вы, вероятно, не программируете на C ++ и не на C #, не так ли?

Есть несколько хороших (частичных) ответов от @Seth (поля работают лучше, поэтому в частном контексте вы также можете использовать это в своих интересах, когда это имеет смысл), @Skurmedel (поля могут быть доступны только для чтения), @Jenk (поля могут быть использоваться для ссылки / выхода). Но хочу добавить еще одно:

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

private int x = 7;

vs

private int x { get; set; }

// This must go in the constructor, sometimes forcing you to create 
// a constructor that has no other purpose.
x = 7;