Tenho observado tanto na prática quanto em alguns materiais que tenho lido, que os itens abaixo são considerados como um design mal feito para uma classe/método:
classe com mais de 200 linhas
métodos com mais de 20 linhas
Porém em algumas situações ter 20 linhas em um método torna-se um grande desafio. Principalmente num cenário onde um determinado serviço, utiliza-se de Criterias da JPA para construir uma consulta dinâmica que depende de uma série de parâmetros (por exemplo, parâmetros enviados por um formulário de filtro de pesquisa).
Gostaria de alguma dica de como melhorar o design de métodos deste tipo.
Quanto às classes, muitas vezes utilizando JSF, ao construir um Backing Bean, muitos atributos precisam estar mapeados para um formulário complexo com listas, combos e etc que devem ser preenchidos e recebidos durante um postback. Com tantos itens a tratar/ preencher em um formulário tenho visto muitos beans criados com 300, 400 e até 500 linhas!
Alguém tem alguma sugestão para melhorar o design neste tipo de cenário também?
Na minha opinião se não passar de 700 já está bom. Claro, se tiver um bom design pode ser até mesmo de umas 1500, mas passou disso não penso duas vezes em quebrá-lo.
A linha de pensamento é a seguinte: um programador de nível médio iria entender este código sem problemas?
Cada caso é um caso. Interprete esses números como um “mau cheiro”, não necessariamente como uma meta.
E essas regras geralmente levam em conta as classes de negócio, não as de interface gráfica.
Hoje levando em conta o “mau cheiro” (termo também utilizado por Fowller ) pude melhorar o design de um Backing Bean em um projeto meu.
Eu tinha um Backing bean, onde o mesmo possuía alguns atributos do tipo List que eram usados para montar combos no meu formulário.
Então resolvi fazer a experiência de colocar cada lista e os métodos para carregar estas listas em Managed Beans (model object - JSF in action) separados.
Este backing bean ficou bem mais enxuto, e lógicas para combo e listas específicas a uma regra do domínio foram quebradas em managed beans.
Com isso pude ganhar em reusabilidade (quanto aos managed beans).
Agora quanto aos métodos que utilizam Criteria para montar queries dinâmicas, alguém conhece algum padrão p/ melhorar este design, ou a maioria tem trabalhado desta forma também?
[quote=adolfo_eloy]Legal pessoal obrigado pelas respostas.
Hoje levando em conta o “mau cheiro” (termo também utilizado por Fowller ) pude melhorar o design de um Backing Bean em um projeto meu.
Eu tinha um Backing bean, onde o mesmo possuía alguns atributos do tipo List que eram usados para montar combos no meu formulário.
Então resolvi fazer a experiência de colocar cada lista e os métodos para carregar estas listas em Managed Beans (model object - JSF in action) separados.
Este backing bean ficou bem mais enxuto, e lógicas para combo e listas específicas a uma regra do domínio foram quebradas em managed beans.
Com isso pude ganhar em reusabilidade (quanto aos managed beans).
Agora quanto aos métodos que utilizam Criteria para montar queries dinâmicas, alguém conhece algum padrão p/ melhorar este design, ou a maioria tem trabalhado desta forma também?[/quote]
Eu comecei um projeto utilizando JSF2 a pouco tempo e tenho reduzido bastante a complexidade dos meus ManagedBeans utilizando o recurso de injeção de dependências via annotation.
Assim eu separo a lógica comum a vários managed beans e reaproveito elas injetando em outros managed beans.
Exemplo:
/**
* The UserLogin Form Component
* @author Pedro T. Oliveira <pedro.oliveira.nom.br>
*/
@ManagedBean
@RequestScoped
public class LoginComponent {
@ManagedProperty(value = "#{loginData}")
private LoginData loginData;
@ManagedProperty(value = "#{loginDataMapper}")
private LoginDataMapper loginDataMapper;
@ManagedProperty(value = "#{loginDataValidator}")
private LoginDataValidator loginDataValidator;
//..... etc....
}
) pude melhorar o design de um Backing Bean em um projeto meu.