Refatorando Padrões

O título é brincadeira, mas reflete bem a realidade, é muito comum encontrar aplicações web que simplesmente acreditam que todos os dados podem ser guardados na sessão. Que a medida que os usuários tem sua sessão invalidada, o garbage collector irá cuidar de destruir tudo.

Este tipo de problema não existiria se a aplicação fosse usada por alguns poucos usuários. Tentem imaginar centenas de atendentes de telemarketing, trabalhando continuamente, entrando em todas as telas possíveis do sistema, executando todo o tipo de ações, e em cada ação mais e mais dados na sessão que somente serão retirados após 6 horas de jornada de trabalho (ou pelo menos deveriam ser 6 horas perante a lei trabalhista, não vou entras nestes detalhes =D). Mas e aí, nestas condições, quanto tempo até chegarmos a um OutOfMemory ?

É muito fácil colocar algo na sessão, por exemplo a lista de cidades de um estado, se a intenção é ajudar no desempenho, esta é a pior estratégia que se pode escolher. Para isso que existem excelentes técnicas de caching e várias bibliotecas que as implementam, a qual garantirá que existe apenas uma única lista em cache para qualquer usuário, além de implementar o padrão Observer para possíveis alterações na lista.

Claro que não estou dizendo que devemos banir o uso de sessões, muito pelo contrário, devemos usá-la, mas tome o cuidado de gerenciar o conteúdo. Um meio simples de se fazer isso é controlar todas as requisições via Servlet Filter em Java ou Filters em Rails, colocando/retirando dados conforme a necessidade.

Tão ruim quanto já colocar tudo na sessão é utilizar péssimas chaves, por exemplo:

Não sabemos de onde veio isso, para onde vai e pior ainda, alguma outra ação pode sobrescrever este valor. Sem uma identificação correta, nem um controle com filtros vai ajudá-lo.

Pensem duas vezes antes de usar o escopo session, em boa parte dos casos usar os escopos page e request é suficiente, analisem cada situação, vai tomar pouquíssimo tempo e cada bit de memória economizado é bem vindo. Há o velho pensamento: "Depois faço um profiling para eliminar alguns gargalos", isto só irá trazer várias dores de cabeça em um código session-macarrônico.

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.