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

Question

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

public int Property {get; set;}

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

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

Answer 4

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

Answer 5

Как правило, рекомендуется скрывать поля за свойствами, даже если вы «точно знаете», что не будете переопределять поле. Слишком часто то, что вы «наверняка знаете» сегодня, меняется завтра. А создание свойства для ссылки на поле - это небольшая проблема.

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

Answer 6

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

Answer 7

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

Answer 8

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