El uso de una gran cantidad de cadenas codificada en código de

Question

Cuando estoy mirando mi código y le escribo cosas como ..

if (role == "Customer") 
{ 
    bCustomer = true; 
} 
else if (role == "Branch") 
{ 
    bIsBranch = true; 
} 

O

foreach(DataRow as row in myDataSet.Tables[0].Rows) 
{ 
    row["someField"]=somefield.Tostring() 
} 

hacen ustedes esto? ¿Cuándo está bien hacerlo y cuándo no deberías estar haciendo esto? ¿Qué pasa si alguno sería un mejor enfoque para escribir esto, si hay alguno?

Gracias por los comentarios: Supongo que debo agregar lo que si (para este ejemplo) solo estoy usando esta comparación de roles una vez? ¿Sigue siendo una mejor idea hacer una clase completamente nueva? Además, si tuviera 1 clase llamada "constantes", ¿hay varias clases que contengan constantes específicas, como la clase "roles", por ejemplo?

Answer 1

No. No utilice "magic strings". En su lugar, crea una clase estática con constantes, o una enumeración si puedes.

Por ejemplo:

public static class Roles 
{ 
    public const string Customer = "Customer"; 
    public const string Branch = "Branch"; 
} 

Uso:

if (role == Roles.Customer) 
{ 

} 
else if (role == Roles.Branch) 
{ 

} 

Aquí hay una good discussion on various solutions.

Answer 2

Bueno, en mi opinión depende de usted y depende del diseño de su aplicación. Lo miro por completo desde el lado positivo: si la aplicación funciona de la manera que se supone que funciona, todo está bien. IMHO

Answer 3

Siempre es mejor declarar las cadenas codificadas por separado como constantes en lugar de declarar una nueva cadena cada vez. Mantiene el código limpio y reduce los errores causados ​​por errores de tipeo.

En relación con lo que debería o no debería hacerse, todo depende del escenario.

Answer 4

Me gustaría hacer una clase estática Roles:

public sealed class Roles 
{ 
    public const string BRANCH = "Branch"; 
    public const string CUSTOMER = "Customer"; 

    public static bool IsCustomer(string role) 
    { 
     return role == CUSTOMER; 
    } 
} 

Luego en el código:

bCustomer = Roles.IsCustomer(role); 

---

Por otra parte, esto requiere un poco más de configuración, pero la RoleProvder (dependiendo de la Web o No) proporciona muchos buenos métodos.

Answer 5

El polimorfismo es una cosa, pero usar cadenas codificadas a lo largo de su código no es nada bueno. Es mucho mejor definir una variable que contenga la cadena y usar esta variable a lo largo del código. Este caso si necesita cambiar algo (créame que lo hará), puede simplemente cambiar el valor de esta variable y está hecho (¡también hay menos errores!)

Answer 6

Creo que un mejor enfoque es usar application settings lo que significa que ganó Nunca debe volver a compilar su código si cambian los valores de "Cliente" o "Sucursal". Los valores mágicos son obviamente malos, y este sería un buen primer paso/opción para alejarse de ellos. Además, mantiene sus valores en un solo lugar, y también creo que puede reload the settings en tiempo de ejecución sin reiniciar la aplicación (aunque yo no lo he probado).

E.g.:

if (role == Properties.Settings.Default.CustomerRole) 
{  
    bCustomer = true; 
} 
else if (role == Properties.Settings.Default.BranchRole) 
{  
    bIsBranch = true; 
} 

Answer 7

Por razones de mantenimiento, se debe formalizar comparadores de cadena cuando sea posible, ya sea como constantes con nombre o como una enumeración. El beneficio para el programador es que puede localizar los cambios. Incluso cuando se utiliza una herramienta de refactorización, encontrar todos los lugares en los que se utiliza una cadena puede ser tedioso y propenso a errores. Es posible que solo tenga un lugar donde haga esta comparación hoy, pero usted o un futuro mantenedor pueden extender esto a otras partes del código. Además, la clase en sí misma puede crecer y debe romperse. Estas cosas tienden a aparecer lentamente en un programa a lo largo del tiempo.

Simplemente declaro estas cadenas como constantes cerca de donde se usan, pero juntas. No se moleste con una nueva abstracción como Roles hasta que sepa que la necesita. Si la cantidad de funciones que necesita para comparar crece o se necesita fuera de esta clase, puede crear una clase Roles enum o Roles, según la complejidad de la comparación.

Además, mediante el uso de constantes, indicas el uso previsto para el compilador, por lo que obtienes algunos beneficios menores de administración de memoria, que, dada tu comparación, es una buena práctica.