A importância do Código Fluente em Java
Não é de hoje que desenvolvemos software. Não é de hoje que temos cada vez mais facilidades para desenvolver mas ao mesmo tempo mais complexidade existe no software que produzimos. Ainda nos dias de hoje é comum achar código que não é fácil de entender. Java é a linguagem mais utilizada no mundo atualmente e é a que possui mais programas prontos rodando diariamente, mas este código Java é simples? Fácil de ler? Rápido de dar manutenção?
O que ocorria antes na era do maiframe era que existia uma preucupação muito grande em "dizer" ao computador o que fazer então a grande preucupação era em fazer o computador entender o que você quer e as precupações da época eram mais com processador, gerência e otimnização de memória, etc...
De lá para cá as coisas mudaram. Na verdade sempre vamos ter mudanças, hoje em dia vejo que é muito importante você escrever um código fácil de ler, rápido de dar manutenção do que o código mais otimizado por que como já dizia o Donald Knuth a otimização prematura é a origem de todo o mal.
Mas para escrever este código mais legivél ou fluente é preciso quebrar paradigmas, esta parte encomoda muita gente, por que como já disse o grande Tom De Marco a primeira reação a mudanças das pessoas é emocional. Mas que paradigmas devem ser quebrados, bom podemos começar com as coisas mais básicas que por incrível que pareça as pessoas não se dão conta. Vou dar alguns exemplos.
Bom gostaria de dizer para vocês que comprei uma nova camera digital que é muito fácil de usar, consigo levar a camera para qualquer lugar e ela funciona via USB em qualquer sistema operacional, olhem só que legal a foto da minha camera.
Qual o problema desta história pessoal? O problema é que quando eu escrevi a palavra "Camera" vocês pensaram em uma coisa, mas quando viram a imagem perceberam que algo estava errado, na verdade vocês se deram conta de que a foto não era de uma Camera e sim de uma Melancia. Agora o que esta loucura tem a ver com desenvolvimento de software e paradigmas.
Tem a ver por que pegamos uma pessímo hábito que eu não sei dizer da onde veio, mas veio e ainda esta presente que é a questão dos "nomes" das coisas. Nomes de váriaveis, nome de classes, nome de métodos. Pessoal isso faz uma imensa diverença na hora de ler e entender o código. Ou alguém acha que a váriavel pedala robinho tem algum coisa a ver com um sistema financeiro?
Existe uma pesquisa clásica que diz que 20% do tempo de vida de um software é projeto e 80% do tempo de vida é manutença. Logo nos dias de hoje precisamos muito pensar e escrever código que é legível. Isso faz muita diferença na hora de fazer namutenção em um sistema e pode fazer você levar mais ou menos tempo para modificar o código.
Continuando nas quebras, outra coisa que acredito que muita gente não se da conta, por exemplo quando criamos um objeto que vai ser persistido no banco de dados sempre colocamos um atributo Long chamado ID, isso não é um conceito de OO e sim na verdade um conceito Relacional do Banco.
Evoluindo mais esta questão é inevitável não chegar em Domain Driven Design. Que na verdade tenta buscar a verdadeira OO que foi desviada pelo padrões que utilizamos hoje em dia como o Modelo Anemico. Esta questão esta muito ligada ao uso de DSL e código fluente.
Vamos ver um exemplo disso em Java, primeiro vou mostrar código usando o Modelo Anemico que normalmente vem utilizado em um Arquitetura MVC com Spring, Hibernate e JSF com pojos, services e daos.Neste caso vamos supor que tenho um sistema de vendas aonde tenho a venda o vndedor o cliente os produtos que são vendidos e um valor de percentual de desconto.
O código para realizar um venda atravéz de um Service(junto ao modelo anemico) seria mais ou menos como o código a baixo:
Bom você deve estar bem familiarizado com este código, que de facto não é complexo de entender, mas ele não é muito legivel e você tem que pensar mais para entender porque se você simplesmente ler pode acabar tendo uma visão errada do que o código faz ou não faz.
Esta questão fica especialemente clara quando você começa a ter mais regras de negocio e vários services chamado outros service e você tem que debugar o código para ver se adivinha o que ele faz. Por que o desenvolvedor que fez não esta mais na empresa ou simplismente não tem mais a menor idéia do que o código fazia.
Usando a técnica de código fluente podemos melhorar muito a legibilidade do código Java e deixando assim ele mais simples e auto-explicativo, confira o código a baixo e tire as suas próprias conclusões:
Bom eu não sei vocês mas este último código é muito fácil de explicar para um usuário normal ou até mesmo para outro programador, agora imagine que você consegue escrever o sistema todo deste jeito, com isso vai ganhar muito em muitos aspectos. As linguagens mais novas e dinamicas tendem a ser muito mais *fluentes* do que o Java, mas o código a cima prova que podemos criar código fluente e legivel em Java sem dificuldade.
Se você estiver curioso para saber como que eu fiz este código, deve estar esperando uma lista de alguns frameworks e configurações e xmls no seu projeto, certo? Errado, não estou usando nenhum framewok, apenas os recursos que a própria linguagen já nos prove. Você pode conferir o código aqui!
Este assunto da muito o que falar e dispera também muitas dúvidas sobre a oque fazer e o que não fazer, valhe a pena muito o leitor estudar e práticar DDD. Eu particularmente acredito que DDD não é uma bala de prata e muito menos uma solução para todos os projeto de todas as empresas, vejo que existem muitas vantagens na utilização da técnica como a comunicação, porem usar o velho modelo anemico não é errado mas para mim é mais complicado em alguns aspectos.
Abraços e até a próxima.
O que ocorria antes na era do maiframe era que existia uma preucupação muito grande em "dizer" ao computador o que fazer então a grande preucupação era em fazer o computador entender o que você quer e as precupações da época eram mais com processador, gerência e otimnização de memória, etc...
Mainframe
De lá para cá as coisas mudaram. Na verdade sempre vamos ter mudanças, hoje em dia vejo que é muito importante você escrever um código fácil de ler, rápido de dar manutenção do que o código mais otimizado por que como já dizia o Donald Knuth a otimização prematura é a origem de todo o mal.
Mas para escrever este código mais legivél ou fluente é preciso quebrar paradigmas, esta parte encomoda muita gente, por que como já disse o grande Tom De Marco a primeira reação a mudanças das pessoas é emocional. Mas que paradigmas devem ser quebrados, bom podemos começar com as coisas mais básicas que por incrível que pareça as pessoas não se dão conta. Vou dar alguns exemplos.
Bom gostaria de dizer para vocês que comprei uma nova camera digital que é muito fácil de usar, consigo levar a camera para qualquer lugar e ela funciona via USB em qualquer sistema operacional, olhem só que legal a foto da minha camera.
Minha Camera Digital Nova
Qual o problema desta história pessoal? O problema é que quando eu escrevi a palavra "Camera" vocês pensaram em uma coisa, mas quando viram a imagem perceberam que algo estava errado, na verdade vocês se deram conta de que a foto não era de uma Camera e sim de uma Melancia. Agora o que esta loucura tem a ver com desenvolvimento de software e paradigmas.
Tem a ver por que pegamos uma pessímo hábito que eu não sei dizer da onde veio, mas veio e ainda esta presente que é a questão dos "nomes" das coisas. Nomes de váriaveis, nome de classes, nome de métodos. Pessoal isso faz uma imensa diverença na hora de ler e entender o código. Ou alguém acha que a váriavel pedala robinho tem algum coisa a ver com um sistema financeiro?
Existe uma pesquisa clásica que diz que 20% do tempo de vida de um software é projeto e 80% do tempo de vida é manutença. Logo nos dias de hoje precisamos muito pensar e escrever código que é legível. Isso faz muita diferença na hora de fazer namutenção em um sistema e pode fazer você levar mais ou menos tempo para modificar o código.
Quebra de Paradigmas
Continuando nas quebras, outra coisa que acredito que muita gente não se da conta, por exemplo quando criamos um objeto que vai ser persistido no banco de dados sempre colocamos um atributo Long chamado ID, isso não é um conceito de OO e sim na verdade um conceito Relacional do Banco.
Evoluindo mais esta questão é inevitável não chegar em Domain Driven Design. Que na verdade tenta buscar a verdadeira OO que foi desviada pelo padrões que utilizamos hoje em dia como o Modelo Anemico. Esta questão esta muito ligada ao uso de DSL e código fluente.
O código para realizar um venda atravéz de um Service(junto ao modelo anemico) seria mais ou menos como o código a baixo:
package com.blogspot.diegopacheco.anoldfashion.using;<br><br>import java.util.ArrayList;<br>import java.util.List;<br><br>import com.blogspot.diegopacheco.anoldfashion.*;<br><br>public class Main {<br> public static void main(String[] args) {<br> <br> Cliente cliente = new Cliente();<br> cliente.setNome("Rafael");<br> <br> Vendedor vendedor = new Vendedor();<br> vendedor.setNome("Abreu");<br> <br> List<Produto> produtos = new ArrayList<Produto>();<br> <br> Produto p1 = new Produto();<br> p1.setNome("Mouse Verde");<br> p1.setValor(10D);<br> <br> Produto p2 = new Produto();<br> p2.setNome("Teclado de Pano");<br> p2.setValor(10D);<br> <br> produtos.add(p1);<br> produtos.add(p2);<br> <br> Desconto desconto = new Desconto();<br> desconto.setPorcetagem(20);<br> <br> Venda venda = new Venda();<br> venda.setCliente(cliente);<br> venda.setVendedor(vendedor);<br> venda.setDesconto(desconto);<br> venda.setProdutos(produtos);<br> <br> VendaService vendaService = new VendaService();<br> Venda vendaSalva = vendaService.salvar(venda);<br> <br> System.out.println(vendaSalva);<br> <br> }<br>}
Bom você deve estar bem familiarizado com este código, que de facto não é complexo de entender, mas ele não é muito legivel e você tem que pensar mais para entender porque se você simplesmente ler pode acabar tendo uma visão errada do que o código faz ou não faz.
Esta questão fica especialemente clara quando você começa a ter mais regras de negocio e vários services chamado outros service e você tem que debugar o código para ver se adivinha o que ele faz. Por que o desenvolvedor que fez não esta mais na empresa ou simplismente não tem mais a menor idéia do que o código fazia.
Usando a técnica de código fluente podemos melhorar muito a legibilidade do código Java e deixando assim ele mais simples e auto-explicativo, confira o código a baixo e tire as suas próprias conclusões:
package com.blogspot.diegopacheco.fluent.interfacejava.using;<br><br>import com.blogspot.diegopacheco.fluent.interfacejava.domain.Vendedor;<br><br>public class Main {<br> public static void main(String[] args) {<br><br> Vendedor.deNome("Abreu").<br> vende().<br> paraCliente("Rafael").<br> oProduto("Mouse Verde").<br> oProduto("Teclado de Pano").<br> comDescontoDe(20).<br> mostrandoDetalhes();<br><br> }<br>}
Bom eu não sei vocês mas este último código é muito fácil de explicar para um usuário normal ou até mesmo para outro programador, agora imagine que você consegue escrever o sistema todo deste jeito, com isso vai ganhar muito em muitos aspectos. As linguagens mais novas e dinamicas tendem a ser muito mais *fluentes* do que o Java, mas o código a cima prova que podemos criar código fluente e legivel em Java sem dificuldade.
Se você estiver curioso para saber como que eu fiz este código, deve estar esperando uma lista de alguns frameworks e configurações e xmls no seu projeto, certo? Errado, não estou usando nenhum framewok, apenas os recursos que a própria linguagen já nos prove. Você pode conferir o código aqui!
Este assunto da muito o que falar e dispera também muitas dúvidas sobre a oque fazer e o que não fazer, valhe a pena muito o leitor estudar e práticar DDD. Eu particularmente acredito que DDD não é uma bala de prata e muito menos uma solução para todos os projeto de todas as empresas, vejo que existem muitas vantagens na utilização da técnica como a comunicação, porem usar o velho modelo anemico não é errado mas para mim é mais complicado em alguns aspectos.
Abraços e até a próxima.
