Está tendo constantes públicas "ruins"?

Em C # é muito ruim por nenhuma das razões mencionadas neste tópico.

As constantes públicas em C # são criadas em assemblies de referência. Ou seja, se você tiver um SomeOtherClass em um assembly separado referenciando SomeString em MyClass, o CIL gerado para SomeOtherClass conterá uma string "SomeValue" codificada.

Se você for reimplantar a dll que contém MyClass, mas não SomeOtherClass e alterar a const, SomeOtherClass não conterá o que você acha que irá - ela conterá o valor original.

Se você é 100% positivo, é uma constante universal como o Pi, enlouquecer; caso contrário, com cuidado.

Esta é uma explicação melhor: link

A alteração de um campo em uma propriedade é uma quebra de alteração. Você perde a compatibilidade com binário, fonte e reflexão.

Além disso:

• There's more fine-grained access control with properties. Need it to be publicly gettable but really only want it set with protected access? No problem (from C# 2 onwards, at least).
• Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter.
• Want to log all access? Just add logging to the getter.
• Properties are used for data binding; fields aren't.

link

Tudo o que disse, não vejo como as constantes são realmente afetadas por isso (especialmente se você não precisa de nenhum dos recursos acima), a menos que sua API mude de tal forma que elas não sejam mais constantes. / p>     

Os perigos dos campos públicos estão no fato de que eles são mutáveis e que a implementação subjacente a eles está sujeita a mudanças.

Quando se trata de um const , isso normalmente não é um problema (da mesma forma que as enumerações públicas) - a menos que você ache que const será mutável e que você precisará de encapsulamento em algum momento ( dizer para registrar quantas vezes ele foi pesquisado), você deve mantê-lo como um public const .

Uma constante é dados. Propriedades implicam a possibilidade de comportamento quando você tanto "olha" para o valor.

O comportamento de empacotamento (ou a sua possibilidade futura) com dados constantes está errado. Para a maioria dos sistemas, isso não importa, mas pode.

Digamos que o valor seja "PI" e usado extensivamente nos cálculos do sistema. Colocá-lo atrás das propriedades forçará os programadores clientes a programarem defensivamente. Eles devem atribuir o valor a uma constante duplicada. Se eles não enganarem, a próxima versão da biblioteca pode ter algum "comportamento" indesejado introduzido por trás da propriedade. O comportamento da propriedade (se estiver em uma biblioteca compilada) é desconhecido. Talvez ele tenha um bom desempenho no teste, mas pode haver códigos ocultos que sejam executados se uma condição especial for atendida. Esta não é uma otimização pré-madura. Especialmente para um sistema em tempo real em que a vida das pessoas depende.

Os programadores clientes podem até perder a segurança de uma constante, pois a linguagem pode não permitir que eles designem um valor de propriedade para sua constante duplicada.

Além disso, quando os programadores são forçados a atribuir o valor de sua propriedade à sua própria constante, eles efetivamente anulam qualquer comportamento que você espera realizar com sua propriedade.

Dados constantes verdadeiros não precisam nem precisam de encapsulamento.