Cada vez que escrevo um método que usa um parâmetro booleano representando uma opção, me pego pensando: "devo substituir isso por uma enumeração que tornaria a leitura das chamadas do método muito mais fácil?".

Considere o seguinte com um objeto que usa um parâmetro informando se a implementação deve usar sua versão thread-safe ou não (não estou perguntando aqui se essa maneira de fazer isso é de bom design ou não, apenas o uso do booleano):

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

Quando a chamada está próxima à declaração, o objetivo do parâmetro parece obviamente óbvio. Quando você está em uma biblioteca de terceiros que você mal conhece, é mais difícil ver imediatamente o que o código faz, comparado com:

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

que descreve a intenção muito melhor.

As coisas pioram quando há dois parâmetros booleanos que representam opções. Veja o que aconteceu comObjectContext.SaveChanges(bool) entre o Framework 3.5 e 4.0. Foi obsoleto porque uma segunda opção foi introduzida e a coisa toda foi convertida em enum.

Embora pareça óbvio usar uma enumeração quando houver três elementos ou mais, qual é sua opinião e experiências sobre o uso de uma enum, em vez de um booleano nesses casos específicos?