.NET: bool vs enum comme paramètre de méthode

Question

Chaque fois que j'écris une méthode qui prend un paramètre booléen représentant une option, je me surprends à penser: "Devrais-je le remplacer par une énumération qui ferait lire les appels de méthode? beaucoup plus facile?". Considérons ce qui suit avec un objet qui prend un paramètre indiquant si l'implémentation doit utiliser sa version thread-safe ou non (je ne demande pas ici si cette façon de faire est bonne ou pas, seulement l'utilisation de le booléen):

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

Lorsque l'appel est à côté de la déclaration, l'objectif du paramètre semble évidemment évident. Quand il est dans une bibliothèque tierce partie que vous connaissez à peine, il est plus difficile de voir immédiatement ce que le code fait, par rapport à:

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

qui décrit l'intention beaucoup mieux. Les choses se détériorent quand il y a deux paramètres booléens représentant des options. Voir ce qui est arrivé à ObjectContext.SaveChanges(bool) entre Framework 3.5 et 4.0. Il a été rendu obsolète parce qu'une deuxième option a été introduite et l'ensemble a été converti en une énumération.

Bien qu'il semble évident d'utiliser une énumération quand il y a trois éléments ou plus, que pensez-vous et que pensez-vous d'utiliser une énumération à la place d'un booléen dans ces cas précis?

Answer 1

.NET 4.0 pourrait aider ici. Vous pouvez utiliser les paramètres nommés:

CreateSomeObject(makeThreadSafe : true); 

Pour les versions plus anciennes, il peut être utile de créer des variables temporaires à la place.

bool makeThreadSafe = true; 
CreateSomeObject(makeThreadSafe); 

Answer 2

Vous pouvez utiliser des paramètres nommés en C# 4.0:

CreateSomeObject(makeThreadSafe : true); 

Answer 3

Il est clair que la seconde approche est plus lisible sans IDE. Si vous êtes en VS, vous pouvez utiliser intellisense pour grok les paramètres, bien que cela puisse être parfois un peu maladroit.

Si vous êtes en C# 4.0, vous pouvez utiliser named parameters pour clarifier votre intention.

Answer 4

Je pense que cela dépend de la sémantique de vos méthodes, par exemple, est-valeur booléenne représente en fait un booléen? Ou est-ce juste pour signaler la présence, pas la présence d'une autre chose?

Par exemple:

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

Même si vous savez (au moins pour l'avenir prévisible qui ne changera pas (sauf si vous voulez soutenir 16 ou même 8 bits), il serait beaucoup plus facile à lire si vous avez utilisé un ENUM:

Options.Use32Bit, 
Options.Use64Bit. 

Answer 5

Pour moi, cela dépend de plusieurs choses:

1. lisibilité
2. Le nombre de paramètres booléens passés dans la méthode
3. La chance que je pourrais avoir besoin plus que vrai/faux

1) Ce qui est plus lisible?

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

2) Et maintenant?

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

3) Je pourrais avoir besoin de quelque chose de plus extensible comme vrai/faux/indéterminé. Si je l'écris de cette façon dès le début, il n'y a pas de changement de rupture si j'ajoute juste un élément supplémentaire à mon énumération.