As variáveis de bandeira são um mal absoluto? [fechado]

Um enorme bloco de funções é o cheiro , não as bandeiras. Se você definir o sinalizador na linha 5, verifique apenas o sinalizador na linha 354, então isso é ruim. Se você definir o sinalizador na linha 8 e verificar o sinalizador na linha 10, tudo bem. Além disso, um ou dois sinalizadores por bloco de código é bom, 300 sinalizadores em uma função é ruim.

Normalmente sinalizadores pode ser completamente substituído por algum sabor do padrão de estratégia, com uma implementação de estratégia para cada valor possível da bandeira. Isso torna a adição de um novo comportamento muito mais fácil.

Em situações críticas de desempenho, o custo da indireção pode vir à tona e tornar necessária a desconstrução em sinalizadores claros. Dito isso, estou tendo problemas para lembrar um único caso em que realmente tive que fazer isso.

Não, sinalizadores não são ruins ou um mal que deve ser refatorado a todo custo.

Considere Java “s Pattern.compile (String regex, sinalizadores int) chamada. Esta é uma máscara de bits tradicional e funciona. Dê uma olhada nas constantes em java e onde quer que você veja um monte de 2 ⁿ você sabe que há sinalizadores ali.

Em um mundo refatorado ideal, seria necessário usar um EnumSet em que as constantes são valores em um enum e conforme a documentação diz:

O desempenho de espaço e tempo desta classe deve ser bom o suficiente para permitir seu uso como uma alternativa de alta qualidade e segura de tipo para “sinalizadores de bit” tradicionais baseados em int.

Em um mundo perfeito, a chamada Pattern.compile torna-se Pattern.compile(String regex, EnumSet<PatternFlagEnum> flags).

Todos dito isso, ainda sinaliza.É muito mais fácil trabalhar com Pattern.compile("foo", Pattern.CASE_INSENSTIVE | Pattern.MULTILINE) do que ter Pattern.compile("foo", new PatternFlags().caseInsenstive().multiline()) ou algum outro estilo de tentar fazer o que as sinalizações realmente são e bom para.

Os sinalizadores são freqüentemente vistos ao trabalhar com coisas de nível de sistema. Ao fazer a interface com algo no nível do sistema operacional, é provável que haja um sinalizador em algum lugar – seja o valor de retorno de um processo, ou as permissões de um arquivo, ou os sinalizadores para abrir um soquete. Tentar refatorar essas instâncias em alguma caça às bruxas contra um cheiro de código percebido provavelmente terminará com um código pior do que se um usado aceitasse e entendesse a bandeira.

O problema ocorre quando as pessoas usam indevidamente as bandeiras jogando-as juntas e criando um conjunto frankenflag de todos os tipos de sinalizadores não relacionados ou tentando usá-los onde não sejam sinalizadores de forma alguma.

Estou presumindo que estamos falando sobre sinalizadores dentro de assinaturas de método.

Usar um único sinalizador já é ruim o suficiente.

Não significará nada para seus colegas da primeira vez que virem. Eles terão que olhar o código-fonte do método para estabelecer o que ele faz. Você provavelmente estará na mesma posição alguns meses depois, quando esquecer do que se trata o seu método.

Passar um sinalizador para o método normalmente significa que seu método é responsável por várias coisas. Dentro do método, você provavelmente está fazendo uma verificação simples nas linhas de:

if (flag) DoFlagSet(); else DoFlagNotSet(); 

Essa é uma separação inadequada de interesses e normalmente você pode encontrar uma maneira de contornar isso.

Normalmente, tenho dois métodos diferentes:

public void DoFlagSet() { } public void DoFlagNotSet() { } 

Isso fará mais sentido com nomes de método que são aplicáveis ao problema que você está resolvendo.

Passar vários sinalizadores é duas vezes pior. Se você realmente precisa passar vários sinalizadores, considere encapsulá-los em uma classe. Mesmo assim, você ainda enfrentará o mesmo problema, pois seu método provavelmente está fazendo várias coisas.

Sinalizadores e a maioria das variáveis de temperatura tem um cheiro forte. Provavelmente, eles poderiam ser refatorados e substituídos por métodos de consulta.

Revisado:

Sinalizadores e variáveis temporárias ao expressar o estado, devem ser refatorados para métodos de consulta. Os valores de estado (booleanos, ints e outros primários) devem quase -sempre- ficar ocultos como parte dos detalhes de implementação.

Sinalizadores que são usados para controle, roteamento e fluxo geral do programa também podem indicar o oportunidade de refatorar seções das estruturas de controle em estratégias ou fábricas separadas, ou o que quer que seja apropriado para a situação, que continue a fazer uso dos métodos de consulta.