Для частных переменных класса, какой из них предпочтительнее?
Если у вас есть свойство типа int limit, вы хотите:
int Limit {get; set;}
и использовать его внутри класса, например:
this.Limit
Есть ли причина использовать его или не использовать? Может быть, по соображениям производительности?
Интересно, это хорошая практика.
Для частного члена я делаю это только при получении и/или установке значения, которое должно вызывать что-то еще, например:
private int Limit
{
get
{
EnsureValue();
return this._limit;
}
}
В противном случае поля будут точными. Если вам нужно увеличить их доступность, это уже достаточно большое изменение, которое делает его собственностью в этот момент, не является огромной сделкой.
Изменить: поскольку Скотт напоминает нам в комментариях, побочные эффекты в свойствах часто могут вызывать больше боли, чем что-либо еще. Не нарушайте Single Responsibility и не ограничивайте логику свойств согласованными логическими операциями только по значению, которое должно выполняться у ворот - например, ленивая загрузка (как в примере выше), преобразование внутренней структуры в общедоступный формат, и др.
Единственное реальное преимущество, которое имеет свойство auto-property по полю, когда доступность является частной, заключается в том, что вы можете установить точку останова при доступе и обновлении переменной. Если это важно для вашего сценария, то обязательно используйте авто-свойство. В противном случае, учитывая, что нет существенного преимущества, я решил пойти с простейшей конструкцией, которая является полем.
Я бы сказал, что его хорошая практика - использовать свойство. Если вам когда-либо приходилось выставлять предельное значение и использовать локальный элемент, ему потребуется больше кодировки, а если его свойство потребует изменения его модификатора.
Я думаю, что он более чистый.
С моей точки зрения использование свойств вместо переменных сводится к:
EnsureValue(),EnsureValue();Не все они относятся к свойствам стиля int Limit {get; set;}.
Конечно, поскольку это частный API, его деталь реализации - вы можете делать все, что хотите. Однако есть очень мало оснований не использовать свойство, даже для частных классов. Свойства встраиваются в JIT, если нет дополнительного кода на месте, поэтому на самом деле это не влияет на производительность.
Самые большие причины предпочитать свойства IMO:
Нет ничего плохого в том, что у вас есть личные или защищенные свойства; это в основном полезно, когда есть некоторое правило или побочный эффект, связанный с базовой переменной.
Причина, по которой свойства кажутся более естественными для публичных переменных, заключается в том, что в общедоступном случае это способ хеджирования одной ставки против будущих изменений в реализации, в результате чего свойство остается неизменным, но детали реализации как-то перемещаются (и/или потребуется дополнительное бизнес-правило).
По производительности это обычно незначительно или действительно идентично для свойств с прямым присваиванием.
Мне лично не нравятся (но часто используют) простые свойства присваивания, потому что они просто загромождают код. Я бы хотел, чтобы С# позволял "после рефакторинга фактов".
Точкой автоматического свойства является то, что они очень быстро создают открытый доступ к некоторому полю вашего класса. Теперь они не приносят никакой пользы, чем подвергать прямые поля внешнему миру, кроме одного большого.
Интерфейс вашего класса - это то, как он общается с внешним миром. Использование автоматических свойств над полями позволяет вам изменить внутренности вашего класса по дороге, если вам нужно сделать настройку значения этого свойства, сделать что-то или проверить правила авторизации или что-то подобное при чтении.
Тот факт, что у вас уже есть свойство, означает, что вы можете изменить свою реализацию, не нарушая публичный интерфейс.
Поэтому, если это просто личное поле, автоматическое свойство на самом деле не так полезно, а не только, но вы не можете инициализировать общедоступные свойства при объявлении, как вы можете, с полями.
Я обычно следую следующему принципу: если он для строго частного использования, используйте поле, поскольку оно быстрее.
Если вы решите, что в какой-то день он станет общедоступным, защищенным или внутренним, в любом случае не сложно реорганизовать свойство, и с помощью таких инструментов, как ReSharper, для этого требуется около 3 секунд...:)
Свойства предоставляют некоторые очень хорошие автоматические функции (например, Json и Xml Serialization)
Поля нет.
Свойства также могут быть частью интерфейса. Если позже вы решите реорганизовать... это может быть и то, что нужно учитывать.
Свойства - это просто синтаксический сахар, С# скомпилирует их в get_PropertyName и set_PropertyName, поэтому различия в производительности не рассматриваются.
Если ваш член данных должен только установить и получить логику, тогда свойства являются очень хорошим и быстрым решением в С#