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

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

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

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

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

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

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

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

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

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

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

public int Property {get; set;}

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

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

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