Marcelo Madeira

IOException + java 6

abril 26, 2007 às 12:26 am | Publicado em Java | 2 Comentários

Lançado no final do ano passado, o java 6 (Mustang) trouxe algumas novidades interessantes. Uma delas é a possibilidade de repassar uma exceção quando for necessário lançar uma IOException. Confuso? Veja o exemplo.

Antes do java 6:

Vejam que não foi possível repassar a exceção lançada pela lógica de negócio (PDFGeneratorException). Para solucionar o problema, foi usado um log para mostrar a exceção.

Agora no java 6:

No java 6 a classe IOException tem um construtor que você pode usar para repassar uma exceção. Com certeza pode ser muito útil par implementar alguma regra.

É claro que o uso de log para mostrar a exceção ainda é muito útil e deve ser utilizado.

Discussão interessante…

abril 15, 2007 às 2:24 pm | Publicado em Java | 2 Comentários

Semana passada surgiu uma discussão muito interessante no projeto que participo.

Qual o tamanho ideal de um método (linhas de código)?

Na minha opinião, um conceito que deve, ou deveria ser, conhecido de todos os profissionais da área é: “Um método deve ser responsável por executar uma tarefa, apenas uma tarefa.”

É praticamente impossível dar manutenção em métodos gigantes, analisar dezenas de if`s, for`s, etc… Sem contar que a probabilidade de se achar um POG é altíssima.

Então qual seria a solução? Simples, divida as responsabilidades. Se seu método precisa fazer uma validação, deixe essa tarefa para outro método e assim por diante. Dividindo resposabilidades você aumentará a manutenabilidade do código.

Um exemplo:

Já vi muito código assim…. rs

——————————————

public void inserir(Contato pContato) throws ExcecaoNegocio {

if ( (pContato.getNome() == null || pContato.getNome().equals(“”)) &&
(pContato.getTelefone() == null || pContato.getTelefone().equals(“”)) ){

throw new ExcecaoNegocio(“Objeto inválido”);

}

dao.inserir(pContato);

}

——————————————

Este exemplo está bonito perto do que vemos por aí…. mas podemos melhorá-lo.

Minha sugestão…

——————————————

public void inserir(Contato pContato) throws ExcecaoNegocio {
if (!validarContato(pContato)){
throw new ExcecaoNegocio(“Objeto inválido”);
}

dao.inserir(pContato);
}

private boolean validarContato(Contato pContato) {
if (verificaVazio(pContato.getNome()) || verificaVazio(pContato.getTelefone())){
return false;
}
return true;
}

private boolean verificaVazio(String pString){
if (pString == null || pString.equals(“”)){
return true;
}
return false;
}

————————————————–

Veja como ficou dividida a responsabilidade entre os métodos.

O método ‘inserir(Contato pContato)’ apenas persiste o objeto. Ele desconhece as regras de validação.

O método ‘validarContato(Contato pContato)’ apenas valida um contato e pode ser utilizado por outros métodos da aplicação (ex: atualizar).

O método ‘verificaVazio(String pString)’ valida se um objeto String possui um conteúdo válido. Apenas isso.

..

Este exemplo bem simples demostra o quanto é importante a divisão de resposabilidades (entre classes, métodos, etc..) para a qualidade de um sistema.

Alguém acrescenta uma sugestão???