A principal razão é que ele acaba dificultando o tratamento de erros da aplicação: ao padronizar o comportamento de alguma operação para uma hierarquia de classes, ele acaba também padronizando as exceções lançadas pelo método, e é aí que está o problema.

Um dos principais problemas que vejo em aplicações legadas é o tratamento de erros feito de forma inapropriada. Já vi algumas pessoas criticando, mas considero um excelente recurso da linguagem Java a existência de Checked Exceptions, utilizadas para erros que podem precisar de um tratamento particular.

Na implementação de uma biblioteca ou de um framework, checked exceptions talvez não sejam tão interessantes. Mas, na implementação de aplicações, considero um recurso bem valioso principalmente para aquelas divididas em camadas.

Template methods não casam bem com checked exceptions pelo seguinte motivo:

abstract protected void validar(Entidade entidade);

abstract protected void logarOperacao(Object algumaCoisa);

public void salvar (Entidade entidade) {
    this.validar(entidade);
    this.dao.persistir(entidade);
    this.logarOperacao(algumaCoisa);
}

Um código como esse é comum em frameworks caseiros ou arquiteturas de referência. Geralmente fica em uma classe chamada MeuManagerGenerico, ou algo do tipo, e as diversas classes de negócio, específicas de cada entidade, devem implementar o método de validação e o método de log. O único problema com está abordagem é que você não está “amarrando” somente a assinatura e o algorítimo para salvar uma entidade, está também dizendo que nenhuma operação “salvar” do sistema lança uma checked exception.

A não ser que sua aplicação seja 100% CRUD, sem nenhuma restrição de unicidade em nenhum atributo, acho que essa é uma restrição muito forte e que não se aplica.

Dessa forma, se alguma regra de validação ou regra de negócio específica não for atendida, como você comunica para a camada superior (provavelmente a camada de visão) sobre o problema ocorrido? A única maneira é lançar unchecked exceptions.

Usando unchecked exception, como as camadas superiores saberão quais exceções lançadas pelas camadas inferiores? A única saída seria a camada inferior antecipar o tratamento dado ao erro, de maneira que a camada superior não precise trata-lo. Já vi muito essa abordagem com a exception tendo como atributo a chave da mensagem que será exibida ao usuário. Dessa forma a camada superior iria somente exibir a mensagem, não importando qual seja a exceção. Isso é um exemplo claro de quebra da divisão de responsabilidade entre as camadas. Se as camadas inferiores tem que antecipar de alguma forma a maneira como as camadas superiores fazem o tratamento de erro, porque você divide sua aplicação em camadas em primeiro lugar?

Esse um bom exemplo de que “amarração de código” e antecipação de necessidades podem trazer prejuízos não antecipados. Imagino que desenvolvedores que fazem template methods para operações com algoritmos simples como “salvar”, “atualizar”, “deletar”, etc só podem ter duas coisas em mente:

1. Economizar código.

Esse pensamento vem do falso sentimento de que uma aplicação enxuta é uma aplicação com pouco código. Temos que tomar cuidado pra não exagerar nas simplificações e não enxergar abstrações onde elas não existem ou são prejudiciais.

2. O desenvolvedor pode esquecer de fazer a validação ou gravar o log ou qualquer coisa do tipo, então “amarra-se” esse algoritmo em um template method.

Se seu desenvolvedor não sabe como fazer uma validação correta ou alguma dessas operações, ele não deveria colocar as mãos no código sem que estivesse fazendo programação em par com outro mais experiente.

Mesmo com essa armadilha, ainda acho válida a utilização do template method, mas somente nos raros casos onde se pode antecipar os erros de toda a hierarquia de classes e quando a complexidade do algoritmo justifique essa abordagem.

Depois de uma análise prévia, vimos que duas soluções poderiam atender nossas necessidades: Glassfish ou Jboss + JON.

O Glassfish é uma promessa que virou realidade, mas confesso que ainda não me convenci, culpa mais pela pouca experiência que tenho com esse servidor do que por sua qualidade, que ele é a melhor solução para o nosso caso. De qualquer maneira, nesses estudos prévios e na apresentação do Kohsuke, acabou subindo muito no meu conceito.

O Jboss já é um velho conhecido e ainda está no páreo, levando em consideração a utilização do JON. O JBoss Operations Network me pareceu ser uma ferramenta realmente fantástica que permite a administração e monitoramento de muitos e muitos e muitos pontos, desde o sistema operacional, passando pelo servidor de aplicação e chegando nas aplicações. Seu lado negativo é que é uma ferramenta paga.

Tomcat está fora da jogada. A maioria das nossas aplicações utilizam Spring, mas algumas mais novas já estão em EJB e futuramente iremos para o Jboss Seam ou Web Beans, como preferirem (também assunto para outro post). Ainda existem algumas outras alternativas, mas a princípio os principais candidatos são esses dois mesmo.

Bem, a análise ainda está em andamento e os principais pontos ques estamos analisando são:

- Administração: facilidade de administrar e monitorar remotamente múltiplas instâncias de servidores.

- Performance: para essa avaliação buscaremos análises de instituições independentes.

- Ambiente de desenvolvimento: facilidades de utilização do servidor de aplicação no ambiente de desenvolvimento:  integração com o Eclipse, tempo de start up e deploy, facilidade de debug, hot deploy, etc.

- Documentação técnica: disponibilidade e qualidade da documentação técnica disponível: manuais, tutoriais, wiki e fóruns

- Suporte técnico: disponibilidade de suporte 24×7. Considerando custo, meio (apenas via web e e-mail ou por telefone também), idioma (em português ou inglês) e tempo de resposta.

- Aderência à especificação: aderência à especificação Java EE 5, incluindo a velocidade em que são lançadas novas versões da ferramenta quando saem novas versões da especificação.

- Custo da migração: custo associado à migração do ambiente atual para o servidor de aplicação escolhido. Atualmente temos aplicações em produção tanto no Jboss quanto no Glassfish

- Custo do software: custo de aquisição de ferramentas necessárias para administração ou desenvolvimento no servidor de aplicação.

- Cases de sucesso: existência de casos de sucesso de sistemas em produção usando o servidor de aplicação.

Estes dois servidores possuem um grande comunidade de usuários, então, caros colegas e recém chegados leitores, sintam-se a vontade e estimulados a deixar algum comentário caso tenham alguma opinião ou experiência relativos a qualquer um desses pontos do Glassfish ou Jboss + JON.