Rodrigo Allemand

Em um ciclo de desenvolvimento em cascata, existe um processo chamado Revisão de Código (Code Review), onde uma pessoa avalia o trabalho de outra pessoa em busca de qualidade, etc. Nas metodologias ageis, esse processo foi substituito por uma ação mais inteligente, que é a Programação em par.

Revisão de código

Sempre me perguntei:

“Como vou deixar claro pra uma pessoa no futuro que o que eu pensei foi asssim, e não assado sem usar somente a documentação?”.

Normalmente, em equipes heterogêneas no carater de senioridade, as solições podem pensar bastante diferente, fazendo com que só a documentação não seja suficiente. E esse cenário de equipes heterogêneas é o mais comum em ambientes de fabricas, onde se misturam plenos - chamados de seniors - com estagiários - chamados de juniors. Então, por ser um processo requerido - por exemplo no CMMi - um pleno desenvolve e um estagiário revisa.

Caso Veridico

Esse lance de revisão me lembra um caso acontecido com um grande amigo meu.

Lá no inicio de vida, a ‘tia’ avisa que fará o ditado do emprego de L e do U, mas que haverá uma surpresa na correção, que será feita pelo coleguinha ao lado. Pois bem, começou o ditado e André foi escrevendo:

1. Salto
2. Alto
3. Saudade
4. …

Ao fim, a professora pede pra trocar com o coleguinha ao lado e André troca com o seu amiguinho Filipe (nome fictício). Ao começar a ver o ditado, André percebe que Filipe inverteu todos os empregos de U x L, colocando Sauto, Auto, Saldade, etc. Com isso, André começou a dar errado em cada item do ditado, fazendo com que Filipe ficasse com zero. André entrega a prova a Filipe e recebe a sua. Ao ver o seu ditado, André fica indignado! Filipe corrigiu tudo como escreveu (Sauto, Auto, Saldade) dando zero para André tambem! (É mais engraçado ele contando…)

Conclusão: Pessoas de niveis diferentes não conseguem estabelecer um nivel de revisão satisfatório.

Programação em Par

Já na programação em par (Pair Programming) as duas pessoas estão no mesmo momento desenvolvendo o código, fazendo com que a conversa, as duvidas e as soluções faça o código sair da melhor maneira possivel para as duas pessoas, evitando retrabalho.

Moral da História: se fosse um ditado em par, de repente, Filipe aprenderia mais rapido e as notas seriam melhores na turma toda.

Obs.: Um ótimo post da InfoQ-Br.

Lembram que nesse post eu falei que o domínio deveria ser fechado e bem definido? Então! A melhor maneira de fazer isso é criar uma camada que faça uma “blindagem” no domínio, definindo o acesso a ela e validando contratos para os métodos.

Contrato nada mais é do que vc garantir que o que entra no domínio está valido e o que sai está de acordo com o que o método se propõe a fazer! Retirado do Wiki do Phillip…

Se quem chamar me garantir a pré-condição, eu garanto a pós-condição.

Garantir a pré-condição é garantir que todos os parâmetros que vc precisa (e recebe) para efetuar uma ação estejam de acordo com uma especificação mínima. Com isso, a pós-condição - que é a sua resposta do método (retorno) - estará garantida.

O padrão utilizado neste caso - para criar uma camada de comunicação do domínio com o mundo - é o Facade (leia-se “Fasseide”, “conjuncão de Face + ade”), um padrão de projeto citado no livro Design Patterns: Elements of Reusable Object-Oriented Softwares, da Gang of Four [Gof]. Ele cita o seguinte:

Fornece uma interface unificada para um conjunto de interfaces em um subsistema. Façade define uma interface de nivel mais alto que torna o subsistema mais facil de ser usado.

A motivação básica desse padrão é dividir sistemas em subsistemas para reduzir a complexidade do código.

Como eu falei anteriormente, um padrão pode ser desenvolvido de diversas maneiras, mas algumas implementações são tão simples que são frequentemente copiadas ao longo dos projetos. A implementação mais comum de Facade é ter um construtor privado - para impossibilitar a criação de uma instancia da classe -  e colocar os métodos da facade como estáticos. Veja o exemplo:

public class Facade {

    private Facade(){
    }

    public static String sayHello(){
        return "Hello World!";
    }
}

Dentro do seu método, vc pode perfeitamente trabalhar da maneira que melhor imaginar, porem, não convem colocar nenhuma regra de negócio ou validação dentro da facade, já que um método interno do domínio pode referenciar outro método do domínio sem necessariamente passar pela facade.

Existem tambem quem utilize uma classe para fachada, criando outras classes mais especificas para controlar cada ação, dividindo o sistema em sub-dominios, chamados por uma mesma fachada.

Blindar e validar sem ter regra de negócio? Para organizar melhor esta bagunça, Martin Fowler e Erick Evans desenvolveram o padrão Specification.

[...] business logic can be recombined by chaining the business logic together using boolean logic.

OBS.: Aqui está o PDF de Fowler sobre Specification.

Com a Specification, vc pode validar, selecionar e até mesmo construir objetos-modelo para satisfazer a sua regra de negócio. Mais uma vez, nenhum padrão tem uma implamentação fixa, todas podem variar, mas a mais utilizada para Specification em Java é a seguinte:

public interface Specification<T> {
    boolean isSatisfiedBy(T t);
}

No exemplo acima, ela retorna true ou false, caso o objeto passado esteja de acordo com a especificação. Esta especificação ainda pode ser de vários tipos, conforme alguns exemplos descrito abaixo:

public abstract class AndSpecification<T> implements Specification<T>{

    private final Specification<T> one;
    private final Specification<T> other;

    //Retorna true se o objeto passar pelas duas especificações
    public AndSpecification(Specification<T> one, Specification<T> other) {
        this.one = one;
        this.other = other;
    }

    public boolean isSatisfiedBy(T t){
        return one.isSatisfiedBy(t) && other.isSatisfiedBy(t);
    }
}

public abstract class OrSpecification<T> implements Specification<T>{

    private final Specification<T> one;
    private final Specification<T> other;

    //Retorna true se o objeto passar por uma das duas especificações
    public OrSpecification(Specification<T> one, Specification<T> other) {
        this.one = one;
        this.other = other;
    }

    public boolean isSatisfiedBy(T t){
        return one.isSatisfiedBy(t) || other.isSatisfiedBy(t);
    }
}

public interface SelectionSpecification<T> {
    //Filtra uma lista de acordo com uma especificação
    List<T> isSatisfiedBy(List<T> list);
}

Utilizando o nosso exemplo, vamos criar um exemplo para validar o cadastro de um usuário:

public class CadastrarUsuarioSpecification
    implements Specification<Usuario> {

    public boolean isSatisfiedBy(Usuario usuario) {
        if(usuario.getNome().equals("") ||
           usuario.getSenha().equals("") ||
           usuario.getLogin().equals("")){
            return false;
        }
        return true;
    }
}

OBS.: Lembrando que isso é apenas um exemplo didático, a entidade usuário do exemplo tem mais campos para serem validados!

O Dominio deve ter a sua validação independente do que vc utilize fora dele, seja Client-side com JavaScript ou Server-Side no seu servlet, por exemplo. Sempre faça o Design By Contract valer no seu domínio.

A especificação CadastrarUsuarioSpecification deve executar todas as validações necessárias para a inclusão de um usuário na base de dados. Utilizando-a em conjuntio com a Facade, teriamos algo como:

public class Facade {

    private Facade(){
    }

    public static void cadastrar(Usuario usuario){
        CadastrarUsuarioSpecification spec =
            new CadastrarUsuarioSpecification();
        if(spec.isSatisfiedBy(usuario)){
            //Cadastrar usuario
        } else {
            //Levantar erro!
        }
    }
}

Com isso, isolamos o domínio, garantimos o contrato e o seu domínio está vacinado conta possiveis erros vindo de outras camadas!

P.S.: Para o conceito de Specification não ficar vago, ainda existem muitos modelos de se contruir uma especificação, seja ela para acesso a banco, para colecionar critérios, para gerar um SQL, para filtrar uma lista, etc. O que precisamos ter em mente é que sempre que vc quizer implementar uma regra de maneira clara, procure ver antes se ela se encaixa em uma specification.

Até!

comente e Recomende!

A peça chave do DDD é a Entidade (Entity).

Entidade é um objeto com um significado para o domínio sendo modelado e que possui uma identidade.

No exemplo dado no decorrer da série de post, basicamente, estas seriam as nossas entidades. Repare que todas as classes possuem uma identidade (o campo ID de cada classe). Isso define uma Entidade: a sua identificação única!

Pensando em um modelo relacional, basicamente, cada entidade representa um registro de uma tabela e as suas referências e dependências. Mas preste a atenção: um modelo relacional é diferente de um modelo de entidades, já que existem diferenças em cada mundo. Veja, por exemplo, a tabela Workflow: não existe referencia a ela como uma classe, mas existe uma coleção, dentro da entidade de Status que referencia esta associação.

DTO x TO x VO x Entidade x Pojo x JavaBean

Vc já ouviu falar de DTO (Data Transfer Object), correto?
E de TO (Transfer Object)?
E de VO (Value Object)?
E de POJO (Plain Old Java Object)?
E de Java Bean?

Se vc acha que é tudo a mesma coisa, vc está enganado!

TO foi citado pelo grupo Core J2EE Patterns inicialmente e foi desenhado para ser usado quando aplicações precdisam se comunicar com EJBs, reduzindo a quantidade de métodos a serem chamados.

DTO segue um proncípio parecido, só não cita EJB e foi descrito por Martin Fowler.

Básicamente, TO e DTO são a mesma coisa, um monte de campos com um bando de métodos acessores (Get e Set) para trafegar informação entre dois “extremos”.

Fowler ainda vai adiante e escreve:

Data Transfer Object is one of those objects our mothers told us never to write. It’s often little more than a bunch of fields and the getters and setters for them. The value of this usually hateful beast is that it
result you need to reduce the number of calls, and that means that you need to transfer more data with each d to procall. One way to do this is to use lots of parameters. However, this is often awkwaronly a single value.often impossible with languages such as Java that return The solution Mels How It Works In many ways, amore than a bun
allows you to move several pieces of information over a network in a single call?a trick that’s essential for
tributed systems.

Já o padrão VO é como se fosse um DTO imutável, ou seja um objeto que mantem o seu valor no decorrer da sua vida. O número 5 sempre vai ser 5. Quando vc muda o 5 pra 6, ele deixa de ser o número 5 e vira o numero 6. Número neste caso é um objeto de valor, um é diferente do outro. Em Java, String, Date, todos os Number. Normalmente

Fowler define Value Object como:

A small simple object, like money or a date range, whose equality isn’t based on identity.

VO não tem identidade, tem valor!

Já o POJO, cunhado por Martin Fowler e cia, são objetos simples. São aqueles objetos que não enxtendem ou implementan ninguem. Não dependem de nenhuma atividade externa. São objetos simples que utilizam somente códigos “nativos de Java”.

E Java Bean? Bem, Java Bean é uma especificação! É ela que diz que as classes devem começar com letra maiúscula, os métodos em minúscula, os getX, setX e isX da vida..

Resumindo:

• Pojo são simples objetos puramente Java;
• JavaBean é uma especificação;
• DTO = TO = Objeto pra transferência de informação;
• VO é um DTO que mantem o seu estado
• Entidade é um objeto que tem uma identidade em um domínio.

Até!

Comente e Recomende!