.NET: bool vs enum come parametro metodo

Question

Ogni volta che sto scrivendo un metodo che accetta un parametro booleano che rappresenta un'opzione, mi trovo a pensare: "dovrei sostituirlo con un enum che renderebbe la lettura del metodo chiamate molto più facile?".

Considerare quanto segue con un oggetto che accetta un parametro che indica se l'implementazione deve utilizzare la sua versione thread-safe o no (non sto chiedendo qui se questo modo di fare questo è un buon design o no, solo l'uso di il booleano):

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

Quando la chiamata è accanto alla dichiarazione, lo scopo del parametro sembra ovviamente ovvio. Quando è in qualche libreria di terze parti si conosce a malapena, è più difficile vedere subito cosa fa il codice, rispetto a:

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

che descrive l'intento di gran lunga migliore.

Le cose peggiorano quando ci sono due parametri booleani che rappresentano le opzioni. Scopri cosa è successo a ObjectContext.SaveChanges(bool) tra Framework 3.5 e 4.0. È stato reso obsoleto perché è stata introdotta una seconda opzione e il tutto è stato convertito in enum.

Mentre sembra ovvio usare un'enumerazione quando ci sono tre elementi o più, qual è la tua opinione e le tue esperienze sull'uso di un enumerico invece di un booleano in questi casi specifici?

Answer 1

.NET 4.0 può essere d'aiuto. È possibile utilizzare parametri denominati:

CreateSomeObject(makeThreadSafe : true); 

Per le versioni precedenti può essere utile invece creare variabili temporanee.

bool makeThreadSafe = true; 
CreateSomeObject(makeThreadSafe); 

Answer 2

È possibile fare uso di parametri denominati in C# 4.0:

CreateSomeObject(makeThreadSafe : true); 

Answer 3

Chiaramente il secondo approccio è più leggibile senza un IDE. Se sei in VS, puoi usare intellisense per ingannare i parametri, anche se a volte questo può essere un po 'maldestro.

Se si è in C# 4.0, è possibile utilizzare named parameters per rendere chiaro il proprio intento.

Answer 4

penso che dipenderebbe semantica dei tuoi metodi, ad esempio, fa il tuo valore booleano in realtà rappresentano un valore booleano? O è usato solo per segnalare la presenza, non la presenza di un'altra cosa?

Ad esempio:

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

Anche se si sa (che almeno per il prossimo futuro che non cambierà (a meno che non si desidera supportare 16 o anche 8 bit) che sarebbe stato molto più facile leggere se si è utilizzato un enum:

Options.Use32Bit, 
Options.Use64Bit. 

Answer 5

Per me dipende da molte cose:

1. leggibilità
2. Il numero di parametri booleani passati nel metodo della
3. La possibilità che potrei avere bisogno di più di una semplice vero/falso

1) Quale è più leggibile?

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

2) Che ne dici ora?

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

3) Potrei aver bisogno di qualcosa di più estendibile come vero/falso/indeterminato. Se lo scrivo così dall'inizio, non c'è alcun cambiamento sostanziale se aggiungo un elemento in più al mio enum.