A orientação geral para C # é sempre usar uma propriedade em um campo público. Isso faz sentido - ao expor um campo, você expõe muitos detalhes da implementação. Com uma propriedade, você encapsula esses detalhes para que não ocorram o consumo de código, e as alterações na implementação são dissociadas das alterações na interface.
No entanto, estou me perguntando se às vezes há uma exceção válida a essa regra ao lidar com a readonly
palavra - chave. Ao aplicar essa palavra-chave a um campo público, você oferece uma garantia extra: imutabilidade. Este não é apenas um detalhe de implementação; a imutabilidade é algo em que um consumidor pode se interessar. O uso de um readonly
campo faz parte do contrato público e algo que não pode ser quebrado por alterações ou herança futuras sem a necessidade de modificar a interface pública. Isso é algo que uma propriedade não pode oferecer.
Portanto, garantir a imutabilidade é uma razão legítima para escolher um readonly
campo em vez de uma propriedade em alguns casos?
(Para esclarecimento, certamente não estou dizendo que você deve sempre fazer essa escolha apenas porque o campo é imutável no momento, apenas quando faz sentido como parte do design da classe e se seu uso pretendido incluir imutabilidade em seu contrato. Estou interessado principalmente em respostas focadas em saber se isso pode ser justificado, em vez de casos específicos em que não é, como quando você precisa que o membro esteja em um interface
ou deseja fazer um carregamento lento.)