Поля vs Свойства для переменных частного класса

Для частных переменных класса, какой из них предпочтительнее?

Если у вас есть свойство типа int limit, вы хотите:

int Limit {get; set;}

и использовать его внутри класса, например:

this.Limit

Есть ли причина использовать его или не использовать? Может быть, по соображениям производительности?

Интересно, это хорошая практика.

Ответы

Ответ 1

Для частного члена я делаю это только при получении и/или установке значения, которое должно вызывать что-то еще, например:

private int Limit
{
   get
   {
       EnsureValue();
       return this._limit;
   }
}

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

Изменить: поскольку Скотт напоминает нам в комментариях, побочные эффекты в свойствах часто могут вызывать больше боли, чем что-либо еще. Не нарушайте Single Responsibility и не ограничивайте логику свойств согласованными логическими операциями только по значению, которое должно выполняться у ворот - например, ленивая загрузка (как в примере выше), преобразование внутренней структуры в общедоступный формат, и др.

Ответ 2

Единственное реальное преимущество, которое имеет свойство auto-property по полю, когда доступность является частной, заключается в том, что вы можете установить точку останова при доступе и обновлении переменной. Если это важно для вашего сценария, то обязательно используйте авто-свойство. В противном случае, учитывая, что нет существенного преимущества, я решил пойти с простейшей конструкцией, которая является полем.

Ответ 3

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

Я думаю, что он более чистый.

Ответ 4

С моей точки зрения использование свойств вместо переменных сводится к:

Pros

  • Можно установить точку прерывания для отладки, как отметил Джаред,
  • Может вызывать побочные эффекты, такие как Rex EnsureValue(),
  • получить и установить могут иметь разные ограничения доступа (public get, protected set),) li >
  • Может использоваться в Редакторах свойств,

Против

  • Более медленный доступ, использует вызовы методов.
  • Объем кода, сложнее для чтения (IMO).
  • Сложнее инициализировать, например, потребовать EnsureValue();

Не все они относятся к свойствам стиля int Limit {get; set;}.

Ответ 5

Конечно, поскольку это частный API, его деталь реализации - вы можете делать все, что хотите. Однако есть очень мало оснований не использовать свойство, даже для частных классов. Свойства встраиваются в JIT, если нет дополнительного кода на месте, поэтому на самом деле это не влияет на производительность.

Самые большие причины предпочитать свойства IMO:

  • Согласованность в вашем API. Вы будете нуждаться в свойствах публично открытых API-интерфейсов, поэтому их использование в частном API сделает ваш опыт программирования более последовательным, что приведет к меньшим ошибкам из-за лучшей ремонтопригодности.
  • Легче конвертировать частный класс в общедоступный

Ответ 6

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

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

По производительности это обычно незначительно или действительно идентично для свойств с прямым присваиванием.

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

Ответ 7

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

Интерфейс вашего класса - это то, как он общается с внешним миром. Использование автоматических свойств над полями позволяет вам изменить внутренности вашего класса по дороге, если вам нужно сделать настройку значения этого свойства, сделать что-то или проверить правила авторизации или что-то подобное при чтении.

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

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

Ответ 8

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

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

Ответ 9

Свойства предоставляют некоторые очень хорошие автоматические функции (например, Json и Xml Serialization)

Поля нет.

Свойства также могут быть частью интерфейса. Если позже вы решите реорганизовать... это может быть и то, что нужно учитывать.

Ответ 10

Свойства - это просто синтаксический сахар, С# скомпилирует их в get_PropertyName и set_PropertyName, поэтому различия в производительности не рассматриваются.

Ответ 11

Если ваш член данных должен только установить и получить логику, тогда свойства являются очень хорошим и быстрым решением в С#