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 preocupação
muito grande em “dizer” ao computador o que fazer. Então a grande
preocupação era fazer o computador entender o que você queria. E as
preocupações da época eram mais com processador, gerência e otimizaçã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, mais do que o código mais otimizado, pois como já dizia o Donald Knuth, a otimização prematura é a origem de todo o mal.

Mas para escrever este código mais legível ou fluente é preciso quebrar
paradigmas. Esta parte incomoda muita gente… Como já disse o
grande Tom De Marco,
a primeira reação das pessoas a mudanças é emocional.

Mas, que
paradigmas devem ser quebrados? 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 câmera digital
que é muito fácil de usar, consigo levá-la para qualquer lugar e
ela funciona via USB em qualquer sistema operacional. Olhem só que
legal a foto da minha câmera:

Minha câmera digital nova

Qual o problema desta história pessoal? O problema é que quando eu
escrevi a palavra “câmera” 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 câmera, e sim de uma melancia.
E o que esta loucura tem a ver com desenvolvimento de software e
paradigmas?

Tem a ver porque desenvolvemos um péssímo hábito, que eu não sei dizer de
onde veio, mas existe e ainda está presente, que é a questão dos “nomes”
das coisas. Nomes de variáveis, nome de classes, nome de métodos.
Pessoal, isso faz uma imensa diferença na hora de ler e entender o
código. Ou alguém acha que a variável “pedala robinho” tem algum coisa a
ver com um sistema financeiro?

Existe uma pesquisa clássica que diz que 20% do tempo de vida de um
software é projeto e 80% do tempo de vida é manutenção. Logo, nos dias de
hoje, precisamos muito pensar e escrever código que seja legível. Isso faz
muita diferença na hora de fazer manutençã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 dá 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, mas 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 pelos padrões que utilizamos hoje em dia, como o Modelo Anemico. Esta questão está muito ligada ao uso de DSL e código fluente.

Vamos ver um exemplo disso em Java. Primeiro vou mostrar o código
usando o Modelo Anemico, que normalmente vem utilizado em um Arquitetura
MVC com Spring, Hibernate e JSF com pojos, services e dados. Neste caso,
vamos supor que tenho um sistema de vendas onde tenho a venda, o
vendedor, o cliente, os produtos que são vendidos e um valor de percentual
de desconto.

O código para realizar um venda através de um Service (junto ao modelo anemico) seria mais ou menos como o código abaixo:

package com.blogspot.diegopacheco.anoldfashion.using;

import java.util.ArrayList;
import java.util.List;

import com.blogspot.diegopacheco.anoldfashion.*;

public class Main {
    public static void main(String[] args) {

        Cliente cliente = new Cliente();
        cliente.setNome("Rafael");

        Vendedor vendedor = new Vendedor();
        vendedor.setNome("Abreu");

        List<Produto> produtos = new ArrayList<Produto>();

        Produto p1 = new Produto();
        p1.setNome("Mouse Verde");
        p1.setValor(10D);

        Produto p2 = new Produto();
        p2.setNome("Teclado de Pano");
        p2.setValor(10D);

        produtos.add(p1);
        produtos.add(p2);

        Desconto desconto = new Desconto();
        desconto.setPorcetagem(20);

        Venda venda = new Venda();
        venda.setCliente(cliente);
        venda.setVendedor(vendedor);
        venda.setDesconto(desconto);
        venda.setProdutos(produtos);

        VendaService vendaService = new VendaService();
        Venda vendaSalva = vendaService.salvar(venda);

        System.out.println(vendaSalva);

    }
}

Bom, você deve estar bem familiarizado com este código, que de fato não
é complexo de entender, mas ele não é muito legível 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 especialmente clara quando você começa a ter mais
regras de negócio e vários services chamando outros services, e você tem
que debugar o código para ver se adivinha o que ele faz, porque o
desenvolvedor que fez não está mais na empresa ou simplesmente 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 deixá-lo, assim, mais simples e
auto-explicativo. Confira o código abaixo e tire as suas próprias
conclusões:

package com.blogspot.diegopacheco.fluent.interfacejava.using;

import com.blogspot.diegopacheco.fluent.interfacejava.domain.Vendedor;

public class Main {
    public static void main(String[] args) {

        Vendedor.deNome("Abreu").
                 vende().
                 paraCliente("Rafael").
                 oProduto("Mouse Verde").
                 oProduto("Teclado de Pano").
                 comDescontoDe(20).
                 mostrandoDetalhes();

    }
}

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. Você só tem a ganhar, em muitos aspectos. As linguagens mais novas e
dinâmicas tendem a ser muito mais “fluentes” do que o Java, mas o
código acima prova que podemos criar código fluente e legível 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 linguagem já nos provê. Você pode conferir o código aqui!

Este assunto dá muito o que falar e também desperta muitas dúvidas sobre o que fazer e o que não fazer. Vale muito a pena estudar e
praticar DDD. Eu particularmente acredito que DDD não é uma bala de
prata e muito menos uma solução para todos os projetos de todas as
empresas; vejo que existem muitas vantagens na utilização da técnica
como a comunicação. Usar o velho modelo anêmico não é errado, mas,
para mim, é mais complicado em alguns aspectos.

Abraços e até a próxima.