Método de Pesquisa Genérico

Depende, o que você acha melhor de ler, um método cheio de parâmetros ou um método recebendo apenas um objeto?

Eu prefiro apenas um objeto e, ao invés de getters e setters, eu faria ele imutável e criado por um builder.

Esse objeto teria apenas um método que configuraria a sua busca (que eu imagino que seja usando o Criteria do Hibernate) ficando mais ou menos assim:

public class FiltroDePesquisa {
   // fields final
   public FiltroDePesquisa (/*... todos os fields ...*/) {/*... atribuições ...*/}

   public void aplicaFiltro(Criteria criteria) {
      // aplica o filtro para os campos necessários com as lógicas necessárias.
   }
}

E assim, você consegue testar.

Obrigado por responder Rafael,

concordo com a abordagem do objeto. No caso, eu tenho um facade com um método pesquisarQualquerCoisa( ObjetoPesquisa objetoPesquisa ) esse ObjetoPesquisa é anêmico, contendo apenas os gets/sets para os possíveis atributos de pesquisa. Dentro do método pesquisarQualquerCoisa eu verificaria quais os atributos estão preenchidos e então montaria a consulta. Teria uma maneira mais elegante de montar essa consulta baseado nos atributos preenchidos do meu ObjetoPesquisa ?

Usando interface e deixando o modelo anêmico de lado.

Algo assim:

public interface Searchable {
   public void apply(Criteria criteria);
}

Assim, você cria vários objetos, um para cada tipo de busca. O nome disso é strategy.

Eu faria usando Builder ao invés de setters.

Só que no caso tenho que manter o modelo anêmico, por escolha do arquiteto, pois segundo ele, não se trata de um modelo anêmico, contudo na minha concepção e acredito que do Martin Fowler também, ter classes burras apenas com gets/sets é um modelo anêmico. Complicou

No caso toda nossa lógica de negócio está em um objeto denominado “GestorObjeto” …

Também não conheço Builders, vou dar uma olhada.

Nesse caso, por decisão do “arquiteto” vocês estão programando estruturalmente.
Pode fazer um método com 200 linhas e sem testes que ele aprova.

De verdade, se ele não deixa você mudar, a sua única saída é fazer um encapsulador desse objeto que vai setar o criteria, do jeito que eu mostrei.

Ai você faz assim:

new ProcessadorDeObjetoPesquisa(objetoPesquisa).processa(criteria);

Acho que é melhor esconder o código feio. Pois ele ainda vai existir. Você vai fazer ifs e mais ifs chamando getters e mais getters…

Você pode até tentar fazer algumas strategies para alguns tipos de Objetos de Pesquisa… Fica melhor, mas ainda feio…

Na verdade estamos desenvolvendo usando BDD, mas a infra é bem pobre mesmo, tendo apenas as classes de dominio anêmicas, gestores encapsulando regras, repositórios e classes de contexto.

Isso não impede que você escreva testes, pelo o contrário, correto?

Bom, se você tem esse modelo para trabalhar, trabalhe nele. Só fico imaginando como são os testes escritos pela equipe.

Isso não impede que você escreva testes, pelo o contrário, correto?

Não, temos testes baseados em comportamentos.

Bom, se você tem esse modelo para trabalhar, trabalhe nele. Só fico imaginando como são os testes escritos pela equipe.

Bem parecidos com testes unitários.