Me he dado cuenta de que he estado haciendo esto de forma inconsistente dentro del mismo proyecto. En algunos lugares, tendré una enumeración con una opción TODO, y en otros tendré mi enum como un tipo anulable con un valor nulo que indica todo (o ningún filtro).¿TODO o nulo con enumeraciones?
Lo noté cuando tenía para escribir algo como if (Region != null && Region != Regions.ALL).
¿Hay alguna razón para ir de una manera u otra?
Dónde enumeraciones que debe especificar un "All" o tipo "nulo", por lo general van con el atributo Flag y utilizan a nivel de bits y &|. Esa es una solución mucho más flexible.
En cuanto a hacer un tipo que admite nulos o tener una opción como "Todo", creo que si tiene sentido para usted, entonces no veo ningún problema con eso. Solo prefiero usar Flags.
Un miembro 'All' es útil para las enumeraciones' [Flags] 'también ... no hay ninguna regla que indique que todas las banderas deben ser mutuamente excluyentes. –
@BenVoigt - totalmente. Cuando tengo este tipo de combinaciones frecuentes, haré un 'All = 0x111' o lo que sea. También puede hacer algo como 'PizzaAndBreadsticks = 0x101' si es un combo frecuente para el que desea una definición explícita. –
El uso de Regions.All es más explícito en cuanto a transmitir el significado. Puede "asignar" ese significado al null, y la computadora estaría bien con él. Los lectores de su programa, sin embargo, tendrían que descifrar ese significado de la forma en que usa el valor de enunciado null, o de leer sus comentarios. Regions.All, por otro lado, es autodocumentable y autoexplicativo.
Generalmente, utilizamos null para indicar 'no especificado' o 'inexistente' o 'no aplicable'. Entonces, en el caso de un filtro, tiene sentido permitir nulo, porque significa "no filtrar".
Además, una enumeración llamada Regions probablemente tiene valores como Northeast, Southeast, Midwest, Southwest y West. Ahora, por favor corrígeme si estoy equivocado, pero no creo que haya ninguna región llamada "Todos" en los Estados Unidos. Durante mi estadía de varios años allí escuché al meteorólogo en el televisor hablando del clima en el oeste, y del clima en el sudeste, etc. pero nunca del clima en algún lugar llamado "Todos". Entonces, me inclino a creer que no existe tal región. Por lo tanto, incluir "Todos" en una enumeración de regiones es un truco. De repente, la enumeración Regions no trata de regiones; en cambio, se trata de regiones y/o filtrado de las mismas. Los cambios en el significado de este tipo son algo a tener en cuenta en la programación y en general evitar.
No estoy de acuerdo con asignar alguna vez null a una variable enum. No se necesita nada para crear un valor de 'None' o' All' que describa perfectamente qué significa 'null' en este contexto. –
@ Hand-E-Food Sí, por supuesto, no requiere nada. Y luego tiene una lista de objetos de 'gerente regional', cada uno de los cuales tiene un campo 'región', y es perfectamente válido tener un gerente regional que administre una región llamada 'Ninguna' o una región llamada 'Cualquiera'.Felicidades, acabas de violar un principio fundamental de integridad de datos. –
Veo su punto ahora que agregar miembros indescrete a lo que debería ser una enumeración discreta es inconsistente. Algo no me sienta bien usando 'null', pero me hace pensar. –
Los nombres de Enum deben ser UpperCamelCase – SLaks
Siento que es un problema de desajuste de impedancia relacional de objeto. En el lado de la aplicación, tiene sentido tener opciones como "Todas", "Todas las regiones de la costa oeste" y "Todas las regiones de la costa este". Sin embargo, a menudo uso enum casted directamente en int como SqlParameter. En estos métodos, necesitaría verificar cada una de estas instancias y convertirlas a SQL apropiado. (En lugar de "y región = 1" necesitaría "y región en (2, 4, 5)"). Lamentablemente, SqlParameters tampoco funciona bien con las listas. – Serinus