Refatorando Padrões

Antes de tudo este post não vai falar sobre física quântica, o objeto Boolean continua sendo aquele já conhecido por nós, mas vou falar sobre um anti-pattern que com certeza fez o Sr. Boole revirar no túmulo e que pessoalmente ainda me causa pesadelos.

Eu estava trabalhando em um módulo de um projeto, a certa altura houve necessidade de se criar uma integração com um outro módulo, nós passaríamos algumas informações, dentre elas indicar ou não se um usuário confirmou uma operação durante o processo, até aí tudo bem, combinamos que para esta confirmação seria passado um Boolean.FALSE ou Boolean.TRUE. Integração implementada e testada.

Após um mês, o mesmo pessoal desta integração me avisa que está tudo errado no conceito da confirmação do usuário, o que outro módulo esperava eram três estados diferentes: se o usuário “disse” NÃO, se o usuário “disse” SIM ou se o usuário não indicou nenhuma das duas opções anteriores… sim eu sei… não fez sentido pra mim também na época, mas acreditem fazia sentido para eles. Mas o problema, é que não houve tempo de opinarmos, o outro lado simplesmente já tinha decidido que seria enviado Boolean.TRUE, Boolean.FALSE ou NULL, caracterizando assim caríssimos, um glorioso mega anti-pattern: um Booleano de três estados. Tentei argumentar para mudarmos para um enum ou pelo menos constantes inteiras, mas não houve acordo, tivemos que aceitar o “monstrinho”, alegaram problemas de tempo para mudanças em vários lugares no módulo, o que já era um sinal de que havia coisas piores.

Lembrem-se, perder um tempo refatorando agora é um tempo ganho no futuro, ganhei várias dores de cabeça por causa desse anti-pattern.

    Nada melhor, quando aprendendo sobre um assunto novo, do que saber o que NÃO fazer. Anti-pattern (Anti-padrões), nada mais são do que programar contra a reusabilidade e flexibilidade.

Óbvio que não é possível programar com a melhor flexibilidade e reusabilidade, aliás nem devemos tentar, como já disse Tony Hoare: “Premature optimization is the root of all evil” (“Otimização prematura é a raiz de todo mal”). Mas devemos sim estar atentos a código inútil, mal escrito ou ambos. É aí que entra o que considere o pior dos anti-patterns. O God object, o objeto que faz tudo, ele é onisciente, conhece a todos e todos dependem dele, assobia e chupa cana ao mesmo tempo, são classes com milhares de linhas, e o pior de tudo, assim como o próprio Deus, ninguém sabe de onde veio e nem para onde vai, mas com certeza levará todo o sistema junto em colapso.

Muito cuidado com esse tipo de objeto, se você notar que sua classe ou mesmo um único método está fazendo mais do que uma tarefa, pare… reflita… e RE-FA-TO-RE, nunca tenha medo de mexer no que está feito, lembre-se que alguns instantes refatorando lhe trará muitos benefícios no futuro.