¿Tener constantes públicas es "malo"?

Es esto:

public MyClass
{
    public const string SomeString = "SomeValue";
}

peor que esto:

public MyClass
{
    public static string SomeString { get{ return "SomeValue";}}
}

Se puede hacer referencia a ambos de la misma manera:

if (someString == MyClass.SomeString)
     ...

El segundo, sin embargo, tiene la protección de ser una propiedad. Pero realmente, ¿cuánto mejor es esto que una constante?

He aprendido una y otra vez los peligros de tener campos públicos. Entonces, cuando vi algo de código usando estas constantes en campos públicos, inmediatamente me puse a refactorizarlas a propiedades. Pero a mitad de camino, me pregunté qué beneficio tenía tener las propiedades estáticas sobre las constantes.

¿Algunas ideas?

En C # es muy malo por ninguna de las razones mencionadas en este hilo.

Las constantes públicas en C # se integran en conjuntos de referencia. Es decir, si tiene SomeOtherClass en un ensamblaje separado que hace referencia a SomeString en MyClass, el CIL generado para SomeOtherClass contendrá una cadena "SomeValue" codificada.

Si va a volver a implementar el archivo dll que contiene MyClass pero no SomeOtherClass y cambia la constante, SomeOtherClass no contendrá lo que cree que contendrá: contendrá el valor original.

Si eres 100% positivo, es una constante universal como Pi, enloquece; de lo contrario, pisar con cuidado.

Aquí hay una mejor explicación: https://stackoverflow.com/questions/55984/what-is-the-difference-between-const-and-readonly

Cambiar un campo a una propiedad es un cambio radical. Pierde compatibilidad binaria, fuente y reflexión.

Adicionalmente:

• Hay un control de acceso más detallado con propiedades. ¿Necesita que se pueda obtener públicamente pero realmente solo quiere configurarlo con acceso protegido? No hay problema (desde C # 2 en adelante, al menos).
• ¿Desea ingresar al depurador cada vez que cambia el valor? Simplemente agregue un punto de interrupción en el setter.
• ¿Quieres registrar todos los accesos? Simplemente agregue el registro al getter.
• Las propiedades se utilizan para el enlace de datos; los campos no lo son.

http://csharpindepth.com/articles/chapter8/propertiesmatter.aspx

Dicho todo esto, no veo cómo las constantes realmente se ven afectadas por esto (especialmente si no necesita ninguna de las características anteriores), a menos que su API cambie de tal manera que ya no sean constantes.

Los peligros de los campos públicos están en el hecho de que son mutables y que la implementación subyacente está sujeta a cambios.

Cuando se trata de constesto, normalmente no es un problema (de manera similar a las enumeraciones públicas), a menos que piense que constterminará siendo mutable y que requerirá encapsulación alrededor del descriptor de acceso en algún momento (por ejemplo, para registrar cuántas veces se miró arriba), bien podría mantenerlo como público const.

Una constante son los datos. Las propiedades implican la posibilidad de comportamiento cuando "miras" el valor.

El comportamiento de agrupamiento (o la posibilidad futura de los mismos) con datos constantes es completamente incorrecto. Para la mayoría de los sistemas, realmente no importará, pero puede.

Digamos que el valor es "PI" y se usa ampliamente en los cálculos del sistema. Ponerlo detrás de las propiedades obligará a los programadores del cliente a programar a la defensiva. Deben asignar el valor en una constante duplicada. Si no se engañan, la próxima versión de la biblioteca podría tener algún "comportamiento" no deseado introducido detrás de la propiedad. Se desconoce el comportamiento de la propiedad (si está en una biblioteca compilada). Tal vez funcione bien en la prueba, pero podría haber código oculto que se ejecute si se cumple una condición especial. Esta no es una optimización pre-madura. Especialmente para un sistema en tiempo real, la vida de las personas depende.

Los programadores del cliente pueden incluso perder la seguridad de una constante ya que el lenguaje puede no permitirles asignar un valor de propiedad en su constante duplicada.

Además, cuando los programadores se ven obligados a asignar el valor de su propiedad en su propia constante, anulan efectivamente cualquier comportamiento que esperaban lograr con su propiedad.

Los datos constantes verdaderos no necesitan ni quieren encapsulación.