c# - programacion - ¿Las variables estáticas deben reemplazarse por enumeraciones?
variables static c# (7)
Creo que deberías usar enumeraciones si tienes un conjunto de valores directamente conectados.
Algo así como: estado enum {Abierto = 1, Cerrado = 2, Esperando = 3};
Para todo lo demás, diría que las variables estáticas son el camino a seguir.
Estaba mirando un código que estaba registrado y me quedé perplejo:
// Amount of days before cancellation can''t be done
enum Cancellation { Limit = 2 };
Al preguntarle al tipo que lo revisó, argumentó que es mucho mejor usar enumeraciones en lugar de variables estáticas, mejor que esto:
private static int CANCELLATION_LIMIT = 2;
Entonces comenzamos a discutir. Mi argumento era que él estaba usando enum como una forma de almacenar valores (se romperá si hubiera dos símbolos enum con el mismo valor). Él argumentó que era un antipattern tener variables estáticas en una clase.
Mi pregunta es ¿qué mejores prácticas deberían usarse para cualquiera de las dos?
Los mensajes están escritos.
Es decir, si tiene un método donde tiene que pasar cierto ''estado'' a un método, por ejemplo, solo puede pasar argumentos ''válidos''. Por ejemplo:
enum OrderState
{
pending = 1,
shipped = 2
}
public IList<Order> GetOrdersInState( OrderState )
{
}
Este es un buen ejemplo -imho- de usar enums. Cuando OrderState es un int para el que crea 2 const ints, no tiene restricciones y puede pasar valores no válidos. El compilador no se quejará.
Sin embargo, en el caso que estás mencionando, creo que usar enums no es una solución válida. Es un uso incorrecto de usar un int, y se debe usar un int int.
Los mensajes son buenos, pero deben usarse donde deben usarse. No son la herramienta preferida en cada situación. Tener una const o var estática no es en este caso un antipatrón.
No creo que CANELLATION_LIMIT
suene como una enumeración, que suele ser un conjunto de opciones.
Para algo diferente, si fue una const
, entonces tal vez ... ¿pero actualmente es un campo mutable?
Tenga en cuenta que las enumeraciones están limitadas a tipos basados en enteros, por lo que no se puede usar para float
, string
, etc.
No sé si es un antipatrón para tener variables estáticas en una clase (?). Por ejemplo, la clase Color en el marco .Net tiene muchas variables públicas estáticas, como Color.Red. Entonces, desde esa perspectiva, estaría de acuerdo contigo.
Sin embargo, puede haber un compromiso: use const privado CANCELLATION_LIMIT = 2; y ambos deberían estar felices. Para él, no habrá una variable global para la clase (?), Ya que las consts serán reemplazadas por el compilador, y obtendrá un único punto de cambio con un nombre claro.
No, ¿cómo se definen las variables de cadena estáticas o los valores decimales en enum?
Para valores inmutables destinados a ser únicos, las enumeraciones son el camino a seguir. La pregunta que debe hacerse es simple: ¿debe el objeto almacenar el valor mismo, incluso estáticamente? En muchos casos, como cuando se describen errores o acciones, la respuesta es no. Recuerde, enum s nació como un reemplazo para #define : asocia valores típicos con identificadores y proporciona un tipo, en realidad no dice "almacenar esta constante aquí".
Supongo que en realidad no desea almacenar nada, pero proporcionar tales valores típicos. los miembros static const solo son útiles cuando tiene la intención de usarlos como tales, por ejemplo, si necesita pasarlos por referencia a un método.
regresar "¿Es lógicamente un conjunto de valores"? "Enum es apropiado": "Const estático está bien"
(Soy un gran admirador de la lógica consistente)