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

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

public string CustomerName;

против

private string customerName;
public string CustomerName
{
get{return customerName;}
set(string value){this.customerName=value;}
}

Ответы

Ответ 1

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

Обратите внимание, что вам не нужен весь последний блок в С# 3:

public string CustomerName { get; set; }

Для получения дополнительной информации см. мою статью "Почему Свойства Материи" .

Ответ 2

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

Ответ 3

Это в основном ошибка в Java. На многих других языках (Python, Delphi, Groovy) компилятор будет генерировать геттеры и сеттеры для вас, если вы не предоставите код.

Это означает, что вы можете использовать "общедоступное" поле в Groovy, и компилятор будет молча генерировать и вызывать setter/setter. Если вам нужно сделать дополнительную магию при изменении поля, вы можете ввести специализированный сеттер, и все будет работать.

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

Ответ 4

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

Ответ 5

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

private int height;
public int Height
{
  get{ return height; }
  set 
  { 
     if (value > 0)
     {
         height = value;
     }
  }
}

Ответ 6

Даже без дополнительной обработки есть еще несколько преимуществ:

Хорошая практика кодирования. В общем, хорошо не выставлять свои поля непосредственно внешним классам, а вместо этого разрешать им доступ только через этот дополнительный уровень абстракции. Даже без дополнительной обработки все равно хорошо быть последовательным, поскольку это может понадобиться где-то еще в коде.
Возможно, вам потребуется изменить поле на свойство позже, когда у вас будет несколько других проектов, зависящих от вашего. Это потребует перекомпиляции всего.
С ними можно использовать события, такие как привязка обработчиков к событиям PropertyChanging или PropertyChanged. В случае полей это невозможно.