2010-02-15 9 views
9

Hasta que me preguntaron question aquí nunca consideré (enums) como algo "malo". Para aquellos que consideran que no son las mejores prácticas, ¿cuáles son algunos enfoques/patrones para evitar su uso en el código?¿Cómo evitar el uso de Enums?

Editar:

public Enum SomeStatus 
Approved = 1 
Denied = 2 
Pending =3 
end Enum 
+5

Ummm ... las enumeraciones fuertemente tipadas son una buena cosa? (sí) –

+0

Solo para aclarar, por "enumeración" se entiende los tipos enumerados, no el uso de la interfaz IEnumerable para representar una secuencia. –

+0

Me dijeron que crean el acoplamiento y las dependencias entre las clases ... – Achilles

Respuesta

9

creo que el uso de una enumeración es una buena cosa. Proporciona seguridad de tipo fuerte.

Tienen algunas desventajas a veces, pero esto generalmente se relaciona con situaciones donde no se conocen todas las opciones posibles de antemano. Si tiene un conjunto fijo de opciones, como su ejemplo, las enumeraciones fuertes escritas a máquina son buenas y no deben evitarse.

+0

De hecho, deberían utilizarse en este caso, en lugar de los códigos 1, 2 y 3 codificados en todas partes. – PostMan

+0

Sí, proporciona un nivel de seguridad y comprensión que no obtendrás usando "números mágicos". –

+2

Pero tenga en cuenta que en realidad no proporcionan seguridad de tipo más que exigir que el valor sea del tipo del tipo subyacente de la enumeración.'status = (SomeStatus) 8374' compilará y funcionará bien, pero probablemente rompa tu código. –

1

Me gustan las enumeraciones para poner nombres fáciles de usar y comprender en conjuntos de valores relacionados. Simplemente no me gusta la implementación de C#. Usando su enumeración de la muestra:

SomeStatus status = 17; 

Esto compila y se ejecuta sin quejarse, a pesar de que 17 es manera de salir de los límites.

Delphi tiene mejores enumeraciones (o al menos, lo que solía - sus muchos años que no lo he usado)

+0

¿Podría explicar en más detalle que "17 está fuera de límites"? –

+1

Los valores especificados en las enumeraciones son 1, 2 y 3. Sin embargo, una variable como mi ejemplo tomará cualquier valor entero, independientemente de si es un valor válido dentro de la enumeración. Creo que eso elimina el aspecto de seguridad de tipo de las enumeraciones. – Ray

+0

No estoy de acuerdo 17 es una enumeración no válida en todos los contextos. Creo que esto es lo que dices, ya que no te gustó la implementación de C#. ¿Qué ocurre si el conjunto de valores de tipo de estado se está definiendo desde una fuente externa y no nos preocupan los valores 4 a 16 de nuestra aplicación? 17 puede ser un valor de enum perfectamente válido en este contexto. En una aplicación en la que trabajé recientemente, teníamos un gran número de enumeraciones que constituían un recurso de idioma y queríamos agrupar los valores enum para la claridad del código. Así que designamos grupos en cientos, donde tal vez solo se usan los valores de 100 a 157, salte a 200 para el siguiente grupo. –

2

El punto principal con la enumeración es que está define en un solo lugar (normalización en la base de datos condiciones). Si esta enumeración es legítimamente parte de la clase que está escribiendo, continúe.

De lo contrario, especialmente si se lo declara más de una vez, vuelva a pensar para qué sirve su enumeración. ¿De verdad está llevando datos? ¿Habrá suficientes valores para considerar almacenar las posibilidades en una base de datos?

24

El problema con enums se describe en Fowler's Refactoring, donde se considera code smell. No tiene nada que ver con la seguridad del tipo, sino que te obliga a rociar las declaraciones switch en todo tu código, violando así el DRY Principio.

El State pattern es un mejor modelo de la misma estructura porque le permite implementar y variar la lógica relacionada con el mismo estado en la misma clase. Esto también aumenta la cohesión y disminuye el acoplamiento de clase.

+1

+1 Me ganaste, buena respuesta. – Luhmann