Общее руководство по C # - всегда использовать свойство над открытым полем. Это имеет смысл - выставляя поле, вы раскрываете много деталей реализации. Со свойством вы инкапсулируете эту деталь, чтобы она была скрыта от потребления кода, а изменения реализации отделены от изменений интерфейса.
Однако мне интересно, есть ли иногда допустимое исключение из этого правила при работе с readonlyключевым словом. Применяя это ключевое слово к общедоступному полю, вы даете дополнительную гарантию: неизменность. Это не просто деталь реализации, потребитель может заинтересовать неизменность. Использование readonlyполя делает его частью публичного контракта, и это не может быть нарушено будущими изменениями или наследованием без необходимости изменять публичный интерфейс. Это то, что недвижимость не может предложить.
Так является ли гарантия неизменности законной причиной выбора readonlyполя над свойством в некоторых случаях?
(Для пояснения, я, конечно же, не говорю, что вы всегда должны делать этот выбор только потому, что поле оказывается неизменным в данный момент, только когда оно имеет смысл как часть дизайна класса и предназначено для включения неизменности в его контракт. В основном меня интересуют ответы, посвященные тому, может ли это быть оправдано, а не конкретным случаям, в которых это не так, например, когда вам нужно, чтобы участник был включен interface, или хотите выполнять ленивую загрузку.)
