Почему никто не принимает публичные поля в C #?

Кажется, что каждый статический анализатор C # хочет жаловаться, когда видит публичное поле. Но почему? Конечно, есть случаи, когда достаточно публичного (или внутреннего) поля , и нет смысла иметь свойство с его get_ и set_ ? Что делать, если я точно знаю, что я не буду переопределять поле или добавлять его (побочные эффекты плохие, верно?) – не должно быть достаточно простого поля?

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

Это действительно о будущем, защищающем ваш код. Когда вы говорите (акцент мой):

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

Это абсолютное утверждение, и, как мы знаем (как и большинство статических анализаторов), в жизни есть только два абсолюта.

Это просто пытается защитить вас от этого. Если это проблема, вы должны иметь возможность сказать анализатору игнорировать ее (через атрибуты, зависящие от используемого инструмента анализа).

Учитывая тот факт, что текущий C # 3.0 допускает автоматические свойства, синтаксис которых подобен:

 public int Property {get; set;} 

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

Во всяком случае, анализатор жалуется на вещи, которые в высоком проценте (в данном случае, например, 99,99% случаев) являются плохой практикой программирования … но в любом случае он просто жалуется. Поля могут быть обнародованы, и есть некоторые крайние случаи, когда его прямое использование может быть оправдано. Как всегда, используйте свой здравый смысл … но имейте в виду элементальное правило для лучших методов программирования … Есть ли действительно веская причина нарушить соглашение? Если есть дальше, если нет, или если ответ «это требует больше работы», тогда придерживайтесь практики …

Поскольку изменение открытых полей позже, чтобы получить / установить аксессоры, нарушит код. См. Этот ответ для получения дополнительной информации.

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

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

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

Еще одна полезная ценность приносит в таблицу при выполнении Reflection. Когда вы размышляете над своим classом, вы можете получить все свойства одним выстрелом, вместо того, чтобы получать свойства AND и поля.

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

  • Свойства и поля: нужна помощь в использовании свойств над полями
  • Автоматически реализованные геттеры и сеттеры против общедоступных полей
  • Отладка автоматических свойств
  • Давайте будем гением компьютера.