Поля по сравнению со Свойствами для частных переменных класса [дубликат]
В порядке парни, это - я снова, и я нашел что-то еще, что удивительно и восхитительно. Это - еще одно сообщение в блоге, упомянутое от другого ТАК вопрос, который упомянул Chris, выше.
подход Этого парня позволяет Вам записать это:
public class WebServer
{
public void BootstrapServer( int port, string rootDirectory, string serverName )
{
Guard.IsNotNull( () => rootDirectory );
Guard.IsNotNull( () => serverName );
// Bootstrap the server
}
}
Примечание, что нет никакой строки, содержащей "корневой каталог" и никакую строку, содержащую "имя сервера"!! И все же его сообщения об ошибках может сказать, что что-то как "Параметр корневого каталога не должно быть пустым".
Это точно, что я хотел и больше, чем я надеялся на. Вот ссылка на сообщение в блоге парня.
И реализация довольно просто, следующим образом:
public static class Guard
{
public static void IsNotNull(Expression> expr)
{
// expression value != default of T
if (!expr.Compile()().Equals(default(T)))
return;
var param = (MemberExpression) expr.Body;
throw new ArgumentNullException(param.Member.Name);
}
}
Примечание, что это использует "статическое отражение", таким образом, в жестком цикле или чем-то, Вы могли бы хотеть использовать подход Rick Brewster выше.
, Как только я отправляю это, я собираюсь голосовать за Chris и ответ на другой ТАК вопрос. Это - некоторый хороший материал!!!
11 ответов
For a private member, I only make it a property when getting and/or setting the value should cause something else to occur, like:
private int Limit
{
get
{
EnsureValue();
return this._limit;
}
}
Otherwise, fields are fine. If you need to increase their accessibility, it's already a big enough change that making it a property at that point isn't a huge deal.
Edit: as Scott reminds us in the comments, side effects in properties can often cause more pain than anything else. Don't violate Single Responsibility and limit property logic to consistent, logical operations on the value only that must be done at the gate - such as lazy loading (as in the example above), transforming an internal structure into a publicly-useful format, etc.
Единственное реальное преимущество автоматического свойства над полем, когда доступ является частным, состоит в том, что вы можете установить точку останова при доступе и обновлении переменной. Если это важно для вашего сценария, определенно используйте автоматическое свойство. В противном случае, учитывая отсутствие существенного преимущества, я предпочитаю использовать простейшую конструкцию, которая представляет собой поле.
Я бы сказал, что использование свойства является хорошей практикой.
Суть автоматических свойств в том, что они очень быстро создают общий доступ к какому-либо полю в вашем классе. Теперь они не предлагают никаких преимуществ по сравнению с открытием прямых полей внешнему миру, кроме одного большого.
Интерфейс вашего класса - это то, как он общается с внешним миром. Использование автоматических свойств над полями позволяет вам изменить внутреннее устройство вашего класса в будущем на тот случай, если вам нужно сделать что-то при установке значения этого свойства или проверить правила авторизации или что-то подобное при чтении.
Тот факт, что вы уже иметь свойство означает, что вы можете изменить свою реализацию, не нарушая публичный интерфейс.
Следовательно, если это просто частное поле, автоматическое свойство на самом деле не так полезно, не только это, но вы можете '
Обычно я следую следующему принципу: если оно предназначено исключительно для личного использования, используйте поле, поскольку оно работает быстрее.
Если вы решите, что когда-нибудь оно станет общедоступным, защищенным или внутренним, В любом случае рефакторинг свойства несложен, а с такими инструментами, как ReSharper, это займет около 3 секунд ... :)
Конечно, поскольку это частный API, это деталь реализации - здесь вы можете делать все, что захотите. Однако очень мало причин не использовать свойство даже для частных классов. Свойства инлайнируются JIT, если нет дополнительного кода, так что на самом деле нет никакого влияния на производительность.
Основные причины предпочтения свойств, IMO, следующие:
- Согласованность в вашем API - вы вам потребуются свойства в публично доступных API, поэтому их включение в частный API сделает ваш опыт программирования более согласованным, что приведет к меньшему количеству ошибок из-за лучшей ремонтопригодности
- Легче преобразовать частный класс в публичный
There's nothing wrong with having private or protected properties; this is mostly useful when there is some rule or side effect associated with the underlying variable.
The reason why properties seem more natural for public variables is that in the public case, it is a way to hedge one's bet against future implementation changes, whereby the property will remain intact but the implementation details somehow move around (and/or some additional business rule will be needed).
On performance, this is typically insignificant, or indeed identical for straight-assignment properties.
I personally dislike (but often use) plain assignment properties because they just clutter the code. I wish C# would allow for "after the fact refactoring".
Свойства - это просто синтаксический сахар, C # скомпилирует их в get_PropertyName и set_PropertyName , поэтому различия в производительности не принимаются во внимание.
Свойства предоставляют очень хорошие автоматические функции (например, Json и Xml-сериализация)
Поля нет.
Свойства также могут быть частью интерфейса. Если вы решите провести рефакторинг позже ... это тоже стоит подумать.
Если вашему элементу данных нужно только установить и получить логику, тогда свойства - очень хорошее и быстрое решение в C #
С моей точки зрения, использование свойств вместо переменных сводится к следующему:
Плюсы
- Может установить точку останова для отладки, как сказал Джаред,
- Может вызвать побочное эффекты, такие как
EnsureValue (), - get и set Рекса могут иметь разные ограничения доступа (общедоступные get , защищенные set ),
- Может использоваться в редакторах свойств,
Минусы
- Более медленный доступ, используются вызовы методов.
- Объемный код, сложнее читать (IMO).
- Сложнее для инициализации, например, требуя
EnsureValue ();
Не все из них применимы к int Limit {get; set;} свойства стиля.