Set programas = WebMediaAPI.listar (new Programas(), new ComTitulo (”Fantastico”));

onde os tais construtores adicionam critérios. Mas é sempre melhor que ter 200 métodos com nomes imensos e cada um deles tendo 40 parâmetros.

Set programas = WebMediaAPI.programas().comTitulo(”Fantastico”).listar();

onde o método “listar” executa a consulta que “programas”, “comTitulo” etc. preparam.

Pense nessa DSL/Fluent Interface como uma camada POR CIMA da API antiga. Ou seja, o funcionamento interno é exatamente o mesmo, só o que muda é a forma que a aplicação é chamada. Você pode considerar essa minha Fluent Interface como uma “Façade” para o resto do sistema.

Dê uma olhada nos posts recentes no meu blog que estou postando algumas coisas sobre DSLs. Dá uma olhada no material e se voce continuar com dúvida me manda uma mensagem e eu tento ajudar mais.

Araços,
Guilherme

No exemplo você apresentou primeiro como era feito antes “getIdsUltimasMidiasPublicadasPorPrograma” e mostrou como ficou depois
“WebMediaAPI.videos().recentes().doPrograma(altasHoras)”. Sei que o post é sobre interfaces fluentes, mas estou com uma dúvida sobre a recuperação dos dados.
Gostaria de saber como foi implementado a recuperação dos dados em ambas as abordagens, por exemplo, imagino que no primeiro método tenha uma consulta que faz vários joins entre as tabelas e devolve o resultado, já no segundo você teria consultas pequenas para cada um dos métodos, foi essa a abordagem adotada?

[]’s

Andrik Albuquerque

Já conhecia o texto do Fowler. Na verdade eu vivo implementando interfaces fluentes o tempo todo, há até uma classe aqui usada assim:
List numeros = sorteador.de(1).ate(20).sortear(1000).maisRepetidos(6);

Que é parte de um testes para candidatos a vagas aqui. Só que, claro, há casos em que Interfaces Fluentes não são necessárias. Como o seu caso possui uma variação muito grande combinações, parece perfeito.

valeuz…

Dá uma lida no artigo do Martin Fowler (http://martinfowler.com/bliki/FluentInterface.html) pra ver o exemplo que tem lá.

O que é melhor, isso:

private void makeNormal(Customer customer) {
Order o1 = new Order();
customer.addOrder(o1);
OrderLine line1 = new OrderLine(6, Product.find(”TAL”));
o1.addLine(line1);
OrderLine line2 = new OrderLine(5, Product.find(”HPK”));
o1.addLine(line2);
OrderLine line3 = new OrderLine(3, Product.find(”LGV”));
o1.addLine(line3);
line2.setSkippable(true);
o1.setRush(true);
}

ou isso:

private void makeFluent(Customer customer) {
customer.newOrder()
.with(6, “TAL”)
.with(5, “HPK”).skippable()
.with(3, “LGV”)
.priorityRush();
}

Como já falei antes, os dois fazem a mesma coisa mas um é muito mais semântico que o outro.

[ ]s, Guilherme

Dessa forma que você propôs você vai ter o mesmo saco de métodos de antes.

Se você fosse implementar todas as variações da minha Fluent Interface dessa sua forma eu chuto que sua classe teria uns 150 métodos (enquanto eu não tenho nenhuma classe com mais de 5 métodos).

Além disso os nomes ficam super toscos. Você pegou um exemplo fácil mas olha esse aqui:

Set videos = api.videosRelacionadosAoCanalDoVideoOrdenadoPorFavoritos(destaquePrincipalGloboVideos, quantidadeMaxima);

Péssimo!

Mas no fim das contas não existe jeito certo ou errado aqui nesse caso. As duas formas são válidas e fazem exatamente a mesma coisa. O caso é que a fluent interface é muito mais elegante.

[ ]s, Guilherme

Set videos = api.videosRecentesDoPrograma(altasHoras);

???