2010-05-25 16 views
7

Za każdym razem, gdy piszę metodę, która przyjmuje parametr boolowski reprezentujący opcję, myślę sobie: "czy powinienem zastąpić to przez wyliczenie, które spowodowałoby odczyt wywołań metod dużo łatwiej?"..NET: bool vs enum jako parametr metody

Rozważmy, co następuje z obiektem, który pobiera parametr informujący, czy implementacja powinna używać wersji wątkowo bezpiecznej, czy też nie (nie pytam tutaj, czy ten sposób jest dobry, czy nie, tylko użycie boolean):

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

Gdy połączenie znajduje się obok deklaracji, cel parametru wydaje się oczywiście oczywisty. Kiedy to w jakiś trzeci biblioteki strona ledwo zna, to trudniej natychmiast zobaczyć, co robi kod, w porównaniu do:

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

który opisuje intencje znacznie lepiej.

Sytuacja się pogarsza, gdy istnieją dwa parametry boolowskie reprezentujące opcje. Zobacz, co stało się z ObjectContext.SaveChanges(bool) między Framework 3.5 a 4.0. Został on przestarzały, ponieważ wprowadzono drugą opcję, a całość została przekształcona w wyliczenie.

O ile wydaje się oczywiste, że używa się wyliczenia, gdy występują trzy elementy lub więcej, jakie są wasze opinie i doświadczenia dotyczące używania wyliczenia zamiast wartości boolowskiej w tych konkretnych przypadkach?

Odpowiedz

7

.NET 4.0 może pomóc tutaj. Możesz użyć nazwanych parametrów:

CreateSomeObject(makeThreadSafe : true); 

Dla starszych wersji może być przydatne utworzenie zmiennych tymczasowych.

bool makeThreadSafe = true; 
CreateSomeObject(makeThreadSafe); 
1

Można skorzystać z wymienionych parametrów w C# 4.0:

CreateSomeObject(makeThreadSafe : true); 
1

Wyraźnie drugie podejście jest bardziej czytelny bez IDE. Jeśli korzystasz z VS, możesz użyć intellisense do pogawędki parametrów, choć wprawdzie czasami może to być trochę niezręczne.

Jeśli jesteś w C# 4.0, możesz użyć named parameters, aby wyrazić swoje zamiary.

2

Myślę, że to zależy od semantyki twoich metod, na przykład czy twoja wartość boolowska faktycznie reprezentuje wartość logiczną? A może służy tylko do oznaczenia obecności, a nie obecności innej rzeczy?

Na przykład:

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

Nawet jeśli wiedzą (że przynajmniej w dającej się przewidzieć przyszłości, która nie ulegnie zmianie (chyba, że ​​chcesz obsługiwać 16 lub nawet 8 bitów) byłoby znacznie łatwiejsze do czytaj jeśli użyto enum:

Options.Use32Bit, 
Options.Use64Bit. 
2

Dla mnie to zależy od kilku rzeczy:

  1. Readability
  2. Liczba logicznych parametrów przekazywanych do metody
  3. Szansa, że ​​mogę potrzebować więcej niż tylko prawda/fałsz

1) Co jest bardziej czytelny?

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

2) Co powiesz teraz?

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

3) Mogę potrzebować czegoś bardziej rozciągliwego, jak true/false/indeterminate. Jeśli piszę to w ten sposób od samego początku, to nie ma zmiany w łamaniu, jeśli dodaję dodatkowy element do mojego wyliczenia.