Fluent Interface

Fluent Interface é usado para deixar o código muito mais limpo, fácil de entender e dar manutenção. A idéia é que o código fique mais parecido com a forma que falamos. Parecido com uma linguagem de  domínio, no nosso caso o Português! Vamos dar um exemplo. Suponhamos que vamos construir uma aplicação simples como um cadastro de clientes. Temos uma funcionalidade que é listar clientes do cadastro. Como você escreveria o código?

1. List<Cliente> clientes = dao.getClientes(); // Lê-se: Get clientes do DAO (isso soa estranho!)

Que tal escrever com mais fluência, assim:

1. List<Cliente> clientes = cadastro.clientes().lista(); // Lê-se Lista os clientes do Cadastro (bom)

Simples? Agora imagine que mudou a funcionalidade do seu sistema e você precisa listar todos os clientes com status ativo. Como poderia ficar seu código na camada de modelo?

1. List clientesAtivos = cadastro.clientes().status().ativo().lista(); // Lê-se: lista clientes do cadastro com status ativo (bem fluente)

Muito parecido como falamos, parecido com uma DSL. Fácil de manter esse código?

Agora vou dar um exemplo e mostrar o código que muita gente ainda faz, e depois vou refatorá-lo para melhor o código.

Seu sistema precisa trazer todos os clientes com status ativo que estão com saldo devedor maior que 10.000 reais. Uma maneira que muita gente faz é:

1. Cliente cliente = new Cliente();
2. cliente.setStatus(Status.ATIVO);
3. cliente.setSaldo(-10000);
4. ClienteDAO dao = new ClienteDAO();
5. List<Cliente> clientes = dao.obterClientes(cliente);

 

Quais são os problemas desse código? Vários! Ele funciona normalmente e vai trazer os resultados esperados, porém ele pode se tornar muito ruim para dar manutenção por não ser fluente. Vamos ver por quê? 

Precisei instanciar um cliente e passei parâmetros para ele, como por exemplo o status e o saldo negativo. Porém a classe Cliente dessa forma está parecendo que não tem inteligência nenhuma, sendo simplesmente uma classe para transportar dados para fazer consulta no banco de dados. Um objeto deve, em termos de Orientação a Objetos, saber o porquê de sua existência e conhecer seus estados válidos. O objeto não deve fornecer métodos que invalidem seu estado, por exemplo cliente.setStatus(’Abobrinha’); Não devemos pensar em uma classe como uma mera coleção de atributos. Objetos também não são atributos mais funções, e sim estado + comportamento. O Phillip Calçado explica muito bem isso! Refatorando a linha 2 ficaria assim:

1. Cliente cliente = new Cliente();
2. cliente.status.ativar();

O benefício disso é a manutenção. Se um dia mudar a regra de um cliente ativo, só será alterado o método ativar(). No primeiro exemplo seria necessário alterar em toda parte da aplicação que fizesse a chamada cliente.setStatus(Status.ATIVO);. Percebemos que um código não está com um bom design quando precisamos fazer muito search para achar as coisas.

Vamos voltar a fluent interface. Outro problema do código acima é o nome do método dao.obterClientes(cliente). Esse método não diz o que ele faz. O desenvolvedor terá então que olhar sua implementação para entender o que o código faz. Isso é muito ruim e atrapalha o desenvolvimento! Uma maneira melhor é então refatorar o código para melhorar o nome do nosso método:

1. List<Cliente> clientesAtivosDeverodes = dao.listaDeClientesAtivosComSaldoDevedorMaiorQue(10000);

Porém o nome desse método está parecendo um pouco macarrônico. Pelo menos é melhor que o anterior, já que agora o desenvolvedor não precisa olhar a implementação para ver o que ele faz. Porém como ficaria isso na fluent interface?

1. List<Cliente> clientesAtivosDeverodes = cadastro.clientes().saldoDevedorMaiorQue(10000).status().ativo().lista();

Ou então você poderia escrever assim:

1. List<Cliente> clientesAtivosDeverodes = cadastro.clientes().status().ativo().saldoDevedorMaiorQue(10000).lista();

Não importa a ordem, pois a fluência é a mesma! Outra coisa interessante é que eu não precisei instanciar um objeto Cliente e passar como parâmetro pois ele foi montado internamente. Portanto a listagem que antes tinha 5 linhas na regra de negócio agora tem apenas 1 linha. E não preciso ler o código de implementação para entender. Manutenção mais simples!

Quando pedimos para trazer os clientes de uma listagem é comum fazermos verificações no código do tipo:

1. if(cliente.getStatus().equals(Status.ATIVO)){ // Le-se: cliente get Status igual status ativo (soa estranho)

A linha acima é ruim pois tem pouca fluência. Melhorando um pouco:

1. if(cliente.isStatusAtivo()){ // Le-se: cliente é status ativo 

E agora com fluent interface:

1. if(cliente.status().isAtivo()){ // Le-se: Status do cliente é ativo (Mais fluente!!)

Mas como fica o código interno para eu fazer a fluent interface? Devo criar classes auxiliares?

Não importa como você vai implementar a fluent interface desde que fique fluente e fácil de manter o código. Não importa se você fizer classe abstrata ou interface, o importante é que o domínio da sua aplicação tenha só o que é referente ao domínio. A programação fica mais intuitiva trabalhando com interfaces ou classes abstratas aplicando fluent interface pois quando pedimos para a IDE listar os métodos só será listado o que faz sentido na fluência.

Vou dar um exemplo de como ficaria a implementação usando interfaces. Não é legal ficar criando classes auxiliares, e sim apenas o que faz sentido no domínio. Preciso, então, criar apenas 2 interfaces e vou utilizar o conceito de Repositório, o qual faz sentido no domínio. Portanto é preciso primeiro entender o conceito de repositório. O código ficaria assim:

1. public interface RepositorioDeClientes {
2.    public RepositorioDeStatus status();
3.    public List<Cliente> lista();
4.    public RepositorioDeClientes obter(Cliente cliente);
5.    public void incluir(Cliente cliente);
6.    public RepositorioDeClientes saldoDevedorMaiorQue(int valor);
7. }

1. public interface RepositorioDeStatus {
2.    public RepositorioDeClientes ativo();
3.    public List<Cliente> lista();
4. }

Agora a classe de implementação. Será nosso DAO.

1. public class ClienteDAO implements RepositorioDeClientes, RepositorioDeStatus{
2.    private Cliente cliente = null;
3.    private List<String> condicoes = new ArrayList<String>(); // para o listar() saber que tem uma condição no where do select. Isso é apenas ilustrativo! Pode ser feito de qualquer maneira.
4.    public List<Cliente> lista(){ 
5.       return null; // TODO fazer a busca no banco. Pode ser hibernate ou qualquer outra coisa
6.    }
7.    public RepositorioDeStatus status(){ 
8.       return this;
9.    }
10.    public RepositorioDeClientes ativo() { 
11.       cliente.status().ativar();
12.       return this;
13.    }
14.    public RepositorioDeClientes obter(Cliente cliente) { 
15.       this.cliente = cliente;
16.       return this;
17.    }
18.    public RepositorioDeClientes saldoDevedorMaiorQue(int valor){
19.       this.cliente.setSaldo(valor); 
20.       condicoes.add(“saldo > “ + valor);
21.       return this;
22.    }

O Guilherme explicou muito bem no blog dele sobre o assunto nesses posts. Vale a pena dar uma espiadinha.

=== EDITADO ===

Um outro bom exemplo de fluent interface é o Criteria do Hibernate.

No meu exemplo os métodos de listagem só terminam com .lista() para que a ordem dos métodos não importasse no resultado final. Mas isso não é regra e pode ser feito de outra maneira para melhor fluência. Outro ponto é eu poderia simplesmente substituir a classe Status por um enum do Java, mas imaginem que o status seja mais complexo que uma simples string “Ativo” ou “Desativado”, mas que tenha toda uma lógica dentro da classe Status. Por esse motivo eu criei a classe Status, apenas para incrementar o exemplo.