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

Ответ 1

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

Ответ 2

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

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

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

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

Ответ 3

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

public int Property {get; set;}

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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