Asesoramiento de diseño en Getter o Const para cadenas en clases: ¿qué están haciendo otros?

Question

Estoy buscando algunos consejos sobre la forma recomendada de usar cadenas 'constantes' dentro de mis clases, p.

public string EmployeesString { get { return "Employees"; } } 

const string EmployeeString = "Employee"; 

La razón me gustaría poner en práctica estos, es decir, ya sea a través de una constante o por medio de un captador, se debe a lo largo de mi clase (s), tengo métodos y constructores que utilizan estas cadenas como parámetros y pensaba para evitar errores tipográficos y también para evitar el uso de cadenas (¿de tipo débil?), quise hacer referencia a ellos con fuerza, por ej.

DoSomething(this.EmployeeString, employee); 

¿Qué son otras acciones? ¡Cualquier consejo será apreciado enormemente! ¿Esto es bueno/malo?

Answer 1

La respuesta "correcta", en mi opinión, depende de cómo y por qué está utilizando la cadena.

Si la cadena se está utilizando para mostrar o presentar a un usuario, entonces la propiedad es un mejor diseño. Esto hace que sea mucho más fácil agregar la localización más tarde al mover la constante en los archivos de recursos, sin tener que cambiar su API. Esto también hace que sea más fácil adaptar tu clase sin romper otro código, ya que puedes cambiar la "constante" en cualquier momento sin romper otros ensambles.

Rara vez encuentro usos apropiados para el segundo caso - muy pocas cadenas son realmente constantes, y cuando lo son, creo que suelen estar mejor representadas como una enumeración en lugar de una cadena. Esto es casi siempre mejor que "cadenas mágicas" en tu código.

Las raras excepciones son típicamente cuando se interactúa con código heredado; si se trata de una API separada que espera una cadena, y la cadena es realmente constante, el uso de una constante es potencialmente "mejor", ya que es más eficiente y muy claro en su intento.

Además, recuerde que los dos enfoques se pueden utilizar juntos:

private const string employeeString = "Employee"; 

public string EmployeeString { get { return employeeString; } } 

Esto le permite utilizar la constante, por lo que es una clara intención, pero fácilmente cambiar esto más adelante sin romper otro código o cambiar su API . (Yo personalmente prefiero esto a su "segunda" opción anterior, ya que la cadena mágica en el getter de propiedad es un olor a código para mí; me gusta que mis constantes sean constantes obvias, pero aún prefiero las propiedades.)

Answer 2

De lo que está hablando, al menos en este ejemplo sería una "Constante". Por lo tanto, el segundo método sería el "más apropiado", al menos en mi opinión.

Answer 3

Las cadenas que va a utilizar para el trabajo de la pantalla o la IU deben colocarse en los archivos de recursos. Esto permite una clave fuertemente tipada, pero también permite una fácil internacionalización de su aplicación, ya que puede obtener el archivo de recursos traducido a un nuevo idioma y se aplicará automáticamente a los usuarios de esa cultura.

Por ejemplo, si coloca un nuevo archivo .resx en su proyecto llamado "ApplicationStrings" y agrega un par clave/valor de "EmployeeString"/"Employee", puede llamarlo a su aplicación de esta manera :

DoSomething(ApplicationStrings.EmployeeString, employee); 

Si ha creado una versión traducida de estas cadenas, digamos que para el español de México, usted acaba de crear un nuevo archivo llamado ApplicationStrings.es-mx.resx. Cuando las personas con la configuración de cultura es-mx utilizaran su programa, ¡usarían automáticamente la versión traducida!

Por lo tanto, las ventajas son bastante claras: valores fuertemente referenciados, localización fácil y administración centralizada de cadenas mágicas en su aplicación.

Incluso para cadenas que no se mostrarán, generalmente creo archivos de recursos para ellas de todos modos, como "InternalStrings.resx". De esta forma, puede usar referencias fuertemente tipadas a "cadenas mágicas" internas que su programa podría necesitar, y si necesita cambiarlas, solo tiene que cambiar el valor en un solo lugar.

Answer 4

Si las cadenas podrían cambiar en el futuro, debe tener un poco de cuidado para hacerlas constantes, al menos si son accesibles a otros ensamblajes, de lo contrario los otros ensamblajes podrían no obtener el nuevo valor si crea una nueva versión del ensamblaje.

Edit: Añadido palabras que faltan

Answer 5

campo const es correcta

Answer 6

Si realmente es una constante que hago esto:

const string EmployeeString = "Employee"; 

Es de lejos la forma más fácil de decir a otros programadores, "Esto no va a cambiar".

public string EmployeesString { get { return "Employees"; } } 

Sin ver dentro del código, no sé qué va a pasar en el descriptor de acceso. Solo sé que hay un descriptor de acceso y recuperaré una cadena. Más adelante en este ejemplo también, alguien podría agregar un conjunto de propiedades, etc. y cambiar el valor de la propiedad en tiempo de ejecución. No puedes hacer eso con una constante.