Refatorando Padrões

Fato interessante ocorreu com uma amiga que estava trabalhando em um JSP enorme, bem que poderia haver menos dados a serem mostrados, mas não sou eu quem decido… enfim… lá pelas tantas, o compilador começou a reclamar de “code too large”, caramba como assim ? Era inserir mais um caracter e dava erro, tirava o caracter e funcionava…

Bom não tem jeito, Google ao resgate… minutos depois problema encontrado e resolvido, o que ocorre é um limitação imposta pelo próprio compilador, um método em Java pode ter um tamanho máximo de 65534 bytes, portanto quando o JSP era convertido em Servlet acabava gerando esse método monstrinho gordinho, mais informações sobre este e outros limites você encontra aqui na especificação da Virtual Machine.

Para resolver o problema foi necessário, adivinhem ? Simmmm, REFATORAR….. basta dividir o JSP em arquivos menores que façam mais sentido e uni-los com <jsp:include>. Para ajudar ainda mais não se esqueça de utilizar padrões web para o HTML gerado, mais tableless, o código fica muito mais enxuto, e quando possível, pense bem antes de criar uma tela com tantos dados, para uma melhor usabilidade.

Claro que, embora seja uma limitação imposta pelo compilador, NUNCA crie um método tão grande, isso vale para qualquer linguagem.

É incrível como aprendemos algo novo todo dia, mesma que a lição venha de forma lenta e dolorosa… recentemente, em uma empresa onde presto serviços em Java, tivemos um problema com o DWR (tenho enorme paixão por este componente, o modo como fizeram a ponte entre Java e Javascript chega a ser mágico, é o estado da arte em uso de Javascript, mas isso fica pra outro ‘post’… =D)

Pois bem, o problema foi ocasionado durante testes de migração pra o JBoss 4.x, a inicialização do DWR estava falhando, não conseguia de forma alguma encontrar as classes informadas em seu arquivo de configuração xml, o famigerado NoClassDefFoundError, algo que não apresentava problemas no JBoss 3.x. Após olhar em empacotamento, meta-infs, jars, configurações do JBoss, nada, nenhuma pista, nem o Google ajudou. O jeito foi descer mais fundo, ler o código fonte do DWR. A linha onde o erro ocorre, executa apenas um carregamento de classe:

this.classDefinition = Class.forName(className) ;

A classe é guardada para que possa ser instanciada por reflexão posteriormente, o interessante é que tudo isso ocorre na inicialização do JBoss, depois que a aplicação levanta, tentamos via debugger, executar o mesmo comando e voilá… funcionava perfeitamente… o que raios estava acontecendo ? Não sabíamos….

Bom, não teve jeito, a classe do DWR teve de ser alterada para testar outra possibilidade de carregamento. Com isso trocamos a linha para:

this.classDefinition = Thread.currentThread().getContextClassLoader().loadClass(className);

Linha monstruosa…. mas funcionou!

Boa prática aprendida: o Class.forName() não sobe na hierarquia de ClassLoader, fica apenas no ClassLoader local, enquanto o ClassLoader.loadClass() sim, ou seja, por questão de robustez e boa prática, sempre utilize a segunda forma, para não ficar com cara de “ué”, quando este tipo de problema surgir.

Mas por que no JBoss 3.x funcionava e no 4.x não ? A resposta é que o ClassLoader o 4.x foi reescrito para ficar mais aderente as especificações, com isso o Class.forName() pegou todo mundo desprevinido, houve claras reclamações da comunidade, mas temos que viver com isso…, existem práticas a serem seguidas.

Ainda bem que não tivemos que usar o código alterado do DWR, estávamos na versão 1.1.3, por curiosidade, baixei a versão estável mais recente (1.1.4) e pra minha grata surpresa essa linha já havia sido alterada do mesmo modo que fizemos , só fiquei chateado por essa alteração não estar presente no release notes, teria me economizado tempo durante busca por pistas…

Certa vez, Nelson, um colega de trabalho, me passou pelo MSN um arquivo entitulado “Standards in a Nutshell.pdf”, abri-o, e como de costume para todo o livro que vejo pela primeira vez, tentei ir direto ao índice, nem paro para ver a capa. Qual não foi minha frustração quando vi que o PDF só tinha uma única página.

“Nelson, acho que aconteceu algum problema, o PDF abriu mas só tem uma página aqui!”

Pensei: “Bom enquanto ele não responde vou dar uma olhada na capa”. Pra minha surpresa, ao vislumbrar a imagem abaixo, percebi que nada havia de errado com o arquivo, lá estava tudo o que precisava ser dito, ou no caso mostrado =D, sobre padrões em um página HTML.

Simples assim.

Tudo que eu já havia lido sobre padrões nessa área, tudo o que muitas pessoas de bom senso pregam como ideal, está aí. Ao invés de um calhamaço de 600 páginas, uma imagem que é compreendida em alguns segundos.

Javascript, CSS e HTML separados. Quem dera todos os designers fizessem isso, as vantagens são absurdas: menos consumo de banda, afinal os mesmos arquivos de CSS e Javascript serão usados em todos os outros arquivos HTML, reusabilidade e o principal, um padrão de separação entre o comportamento e apresentação da página, maravilhas das maravilhas para futuras manutenções. Basta apenas ligar os arquivos .css e .js com uma tag no arquivo HTML e pronto.

É claro que não poderia deixar de dar crédito a autora pela obra de arte.

Standards For Life

Preciso criar um cartaz bem grande com isso, talvez alguém olhe e crie juízo. =D

    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.