.NET: bool vs enum como un parámetro de método

Question

Cada vez que escribo un método que toma un parámetro booleano que representa una opción, me encuentro pensando: "¿Debería reemplazar esto por una enumeración que haría leer las llamadas al método? ¿más fácil?".

Considere lo siguiente con un objeto que toma un parámetro que indica si la implementación debe usar su versión segura para subprocesos o no (no pregunto si esta manera de hacerlo es buena o no, solo el uso de el booleano):

public void CreateSomeObject(bool makeThreadSafe); 
CreateSomeObject(true); 

Cuando la llamada está al lado de la declaración de la finalidad del parámetro parece obvio, por supuesto. Cuando está en alguna biblioteca de terceros que apenas conoce, es más difícil de ver de inmediato lo que hace el código, en comparación con:

public enum CreationOptions { None, MakeThreadSafe } 
public void CreateSomeObject(CreationOptions options); 
CreateSomeObject(CreationOptions.MakeThreadSafe); 

que describe la intención mucho mejor.

Las cosas empeoran cuando hay dos parámetros booleanos que representan las opciones. Vea lo que pasó con ObjectContext.SaveChanges(bool) entre Framework 3.5 y 4.0. Se ha quedado obsoleto porque se ha introducido una segunda opción y todo se ha convertido en una enumeración.

Si bien parece obvio utilizar una enumeración cuando hay tres elementos o más, ¿cuál es su opinión y experiencia sobre el uso de una enumeración en lugar de una booleana en estos casos específicos?

Answer 1

.NET 4.0 podría ayudar aquí. Puede usar parámetros con nombre:

CreateSomeObject(makeThreadSafe : true); 

Para versiones anteriores, puede ser útil crear variables temporales en su lugar.

bool makeThreadSafe = true; 
CreateSomeObject(makeThreadSafe); 

Answer 2

Puede hacer uso de parámetros con nombre en C# 4.0:

CreateSomeObject(makeThreadSafe : true); 

Answer 3

Es evidente que el segundo enfoque es más legible sin un IDE. Si está en VS, puede usar intellisense para asimilar los parámetros, aunque a veces esto puede ser un poco torpe.

Si se encuentra en C# 4.0, puede usar named parameters para aclarar su intención.

Answer 4

creo que dependerá de la semántica de sus métodos, por ejemplo, ¿su valor booleano en realidad representan un valor lógico? ¿O se usa solo para marcar la presencia, no la presencia de otra cosa?

Por ejemplo:

// If true, uses 64 bit numbers, if false, 32. 
doSomething(boolean) 

Incluso si usted sabe (que al menos en el futuro previsible que no va a cambiar (a menos que quiera apoyar a 16 o incluso 8 bits) sería mucho más fácil leer si se ha utilizado una enumeración:

Options.Use32Bit, 
Options.Use64Bit. 

Answer 5

Para mí depende de varias cosas:

1. legibilidad
2. El número de parámetros booleanos aprobadas en el método
3. La posibilidad de que yo podría necesitar algo más que verdadero/falso

1) ¿Qué es más fácil de leer?

CreateSomeObject(CreationOptions.MakeThreadSafe); 
CreateSomeObject(true); 

2) ¿Qué tal ahora?

CreateSomeObject(CreationOptions.MakeThreadSafe, ExtraGoodies.Include, Logging.Disable); 
CreateSomeObject(true, false, false); 

3) Es posible que necesite algo más extensible como verdadero/falso/indeterminado. Si lo escribo de esta manera desde el principio, no hay cambio de ruptura si simplemente agrego un elemento adicional a mi enumeración.