Depois de uma longa espera, temos o tão aguardado lançamento. O livro está sendo distribuído para as livrarias, e já é bem fácil encontrá-lo nas lojas online, como na Saraiva.

Foi bastante tempo e trabalho para criar uma introdução abrangente, e ao mesmo tempo com uma necessária profundidade, de alguns dos principais tópicos da plataforma Java. Em vez de apresentar respostas e fórmulas prontas, procuramos colocar questões para que os trade-offs tornem-se bem visíveis. Passamos por detalhes da JVM e design de classes até uso de frameworks, serviços, testes e automação.

Você pode encontrar detalhes do livro, conteúdo, além de algumas seções para ler no site oficial.

Haverá uma confraternização em São Paulo, dia 26 de janeiro, às 19h00, na Saraiva do Shopping Paulista, comemorando o lançamento do livro. Você está convidado!

Esperamos que aproveite nosso trabalho, e agradecemos a todos alunos, desenvolvedores e instrutores que possibilitaram essa realização.

Uma das features interessantes do Hibernate é gerar a Data Definition Language para criação da estrutura de tabelas do banco de dados (schema). Tudo que precisamos fazer é pensar em nosso modelo Orientado a Objeto que o banco é gerado automaticamente a partir das entidades. Aparentemente o processo de pensar na modelagem do banco de dados tornou-se obsoleto: é aí que mora o perigo.

Na orientação a objetos é preferível favorecer especialização através da divisão de responsabilidades. Em vez de criar uma classe gigantesca devemos quebrá-la em pequenas classes.

Quando o assunto é banco de dados a análise é bem diferente. No modelo relacional, a preocupação é normalização dos dados e a modelagem ao mesmo tempo tende a ser pensada de forma a evitar a necessidade de alguns joins que seriam mais caros. Muitas vezes é preferível criar uma tabela com várias colunas com todas as informações pertinentes a criar várias tabelas especializadas. Para ilustrar, considere as entidades:

@Entity
public class Produto {
  @Id
  @GeneratedValue
  private Long id;
  private String nome;
  private BigDecimal preco;
  private Calendar inicioPeriodoPromocional;
  private Calendar fimPeriodoPromocional;
  // outros atributos e metodos
}

@Entity
public class Promocao {
 private Calendar inicio;
 private Calendar fim;
 //outros atributos e metodos
}

Suponha que gostaríamos de saber se uma promoção é aplicável a um produto e por quantos dias podemos aproveitar uma promoção. Colocar esse código dentro de um controller ou managed bean não parece uma boa idéia. Esse trecho rapidamente reaparecerá em outro lugar. Onde então podemos criar métodos para essa análise? Poderíamos começar criando a classe Intervalo:

public class Intervalo {
  private Calendar inicio;
  private Calendar fim;
}

E em vez de Produto e Promocao guardarem referências para duas datas, guardariam para um Intervalo, removendo os respectivos Calendars:

@Entity
public class Produto {
  @Id
  @GeneratedValue
  private Long id;
  private String nome;
  private BigDecimal preco;
  private Intervalo periodoPromocional;
  //...
}

@Entity
public class Promocao {
  private Intervalo vigencia;
  //...
}

A criação da classe Intervalo pode trazer benefícios muito maiores do que a eliminação da repetição de atributos. Adotando a boa prática de unir dados a comportamentos, podemos isolar todo comportamento relacionado a um intervalo de datas nessa nova classe:

public class Intervalo {
  private Calendar inicio;
  private Calendar fim;

  public int getDias() {...}
  public Intervalo interseccaoCom(Intervalo outro) {...}
}

Para saber quantos dias temos para aproveitar a promoção faríamos:

Intervalo janelaDeOportunidade =
  produto.getPeriodoPromocional().interseccaoCom(promocao.getVigencia());

int diasParaAproveitar = janelaDeOportunidade.getDias();

Mas como mapeamos a classe Intervalo? Criar uma tabela e referenciar seus registros através de chaves estrangeiras nas tabelas Produto e Promocao só trará a necessidade de joins. A JPA nos oferece uma alternativa: criar uma classe Embeddable, um dos assuntos básicos abordados no FJ-25. Quando anotamos uma classe com @Embeddable, seus atributos serão colunas na tabela da entidade que tem o atributo anotado com @Embedded.

@Embeddable
public class Intervalo {
  //...
}

@Entity
public class Promocao {
  @Embedded
  private Intervalo vigencia;
  // a tabela Promocao terá uma coluna inicio e outra fim
  // ...
}

A classe Intervalo não precisa de um identificador único: ela é definida pelo seu valor e pode ser encarada como um Value Object. É importante conhecer os diversos recursos do Hibernate que nos dão a possibilidade de não precisar adequar nossas entidades às nossas tabelas, nem de adequar nossas tabelas às nossas entidades. Por exemplo, tabelas secundárias oferecem o serviço inverso: uma entidade mapeada em duas tabelas. O próprio @ManyToMany evita a criação de uma classe a mais apenas para manter referências para as duas classes relacionadas. Há ainda o suporte a chaves compostas, herança, nomenclatura das tabelas, namespaces e colunas, e até mesmo tipos definidos pelo próprio usuário para cada banco de dados diferente.

Um dos pontos difíceis de lidar em qualquer sistema está ligado com quebra de encapsulamento. Em Java, uma vez que o padrão de uma variável membro permite que ela seja acessada por fora do objeto, protegemos os dados através do modificador private e um getter:

public class Conta {
  private List<Movimentacao> movimentacoes = new ArrayList<Movimentacao>();
  private double saldo;

  public double getSaldo() {
    return saldo;
  }

  public List<Movimentacao> getMovimentacoes() {
    return movimentacoes;
  }
}

Enquanto a criação de getters é um padrão amplamente adotado, muitas vezes ainda deixamos vazar os objetos mutáveis, como no caso da lista acima. Para não vazar referências a tais objetos, quebrando o encapsulamento e possívelmente alguma funcionalidade interna, retornamos uma cópia segura da mesma:

  public List<Movimentacao> getMovimentacoes() {
    // protegendo a lista interna para não quebrar o encapsulamento
    return Collections.unmodifiableList(movimentacoes);
  }

A criação de getters e setters deve ser feita com cuidado: uma vez que a implementação é exposta através de um getter e setter, a remoção dele, para finalmente encapsulá-lo, implica na mudança de todas as chamadas a ele. Em Ruby, o mesmo cuidado pode ser tomado:

class Conta
  def movimentacoes
    @movimentacoes.dup
  end
end

Em Scala, existem diversas variações para declaração de variáveis membro. A padrão que ainda nos ajuda a criar good citizens, é a definição de uma variável privada, final:

class Conta(saldo:Double)

A desvantagem é que as vezes é interessante colocar um getter para expor o conteúdo referenciado. No caso de uma conta bancária, é interessante expor o saldo da mesmo, mas não uma lista de movimentações sem protegê-la.

Para isso, podemos definir uma val (equivalente a variáveis final em Java), uma vez que o papel do getter é gerado automaticamente pelo compilador (nomes de variáveis e métodos estão no mesmo contexto, portanto não requerem recompilação quando um substitui o outro):

class Conta(val saldo:Double)

A desvantagem pode estar em desejar alterar o saldo da conta e não poder. Nesse caso definiríamos o membro como var:

class Conta(var saldo:Double)

A desvantagem nessa abordagem é a criação do getter e do setter de exposição: ao definir uma variável como “private” mas permitir o acesso a mesma, o encapsulamento é novamente quebrado. Portanto, para membros cuja referência pode ser alterada (vars), é interessante gerar o “getter” mas não expor o setter para não quebrar o encapsulamento, como em:

class Conta(private var _saldo:Double) {
  def saldo = _saldo
}

Mas nesse caso, o código deixa de ser curto como nas abordagens onde o encapsulamento é mais facilmente quebrado. O mesmo é válido para muitas linguagens: é mais fácil quebrar o encapsulamento dos objetos do que executar a troca de mensagens para efetuar uma transferência:

class Conta(private var _saldo:Double) {
  def saldo = _saldo
  def debita(valor:Double) {
    movimentacoes.add(new Movimentacao(-valor));
    _saldo -= valor
  }
}

O encapsulamento é a base de orientação a objetos. Nos momentos em que é adequado trabalhar de forma OO, é ele que permite a troca de mensagens entre objetos prevenindo o usuário de depender de como o tipo funciona internamente. Das maneiras demonstradas aqui, escolha a maneira de encapsular suficientemente adequada para faciltiar a manutenção de suas classes a longo prazo (para evitar quebras inesperadas).

Como pergunta, será que seria interessante a linguagem fornecer uma opcao só de getter para var?

Escrever testes de unidade é uma prática cada vez mais adotada. Ela ajuda a verificar se tudo funciona como o esperado mesmo após mudanças, trazendo mais segurança para a equipe ao alterar o código. Mas os testes de unidade vão além, possibilitando a validação de um design.

Um código fácil de testar tende a apresentar um bom design. Existe uma grande sinergia entre testabilidade e um bom design. Isso acontece pois, para que o programador consiga testar uma classe de maneira isolada e facilmente, essa classe deve lidar muito bem com suas dependências (buscando sempre um baixo acoplamento) e possuir pouca responsabilidade (ou seja, ser altamente coesa). Caso contrário, o programador gastará muito tempo tentando testá-la, um possível indicador de que a classe apresenta um design pobre.

Um design que apresenta classes com alto acoplamento são difíceis de testar, surgindo a necessidade de passar as dependências para nossos objetos e só então testá-los.

O primeiro resultado ao adicionar testes de unidade a um sistema é a mudança de padrões imperativos de execução onde instanciamos objetos e invocamos métodos para a injeção de dependências.

O exemplo a seguir mostra um processador sendo instanciado, o que torna difícil verificar se o comportamento do ExecutorDeBatch foi correto sem executar o código da classe Processador:

public class ExecutorDeBatch {
  public void le(ListaDeItens itens) {
    Processador processador = new Processador();
    while(itens.temProximo()) {
       String item = sc.proximo();
       processador.interpreta(item);
    }
  }
}

O teste acima verifica o comportamento do ExecutorDeBatch junto com o Processador. Esse tipo de teste é considerado de integração, não passando muita informação sobre o acoplamento entre as classes, mas somente garantindo o comportamento em conjunto.

Para isolar a classe acima seria necessário a utilização de um mock no lugar do Processador. Da maneira que o código está, seria bastante trabalhoso. No Java exigiria até manipulação de bytecode durante o classload para que fosse possível alterar a classe instanciada no momento do new Processador() por exemplo. Para isso, o programador deve deixar essas dependências bem explícitas, recebendo-as através do construtor, por exemplo. Teríamos então o seguinte código:

public class ExecutorDeBatch {
  private Processador processador;
  public ExecutorDeBatch(Processador processador) {
    this.processador = processador;
  }

  public void le(ListaDeItens itens) {
    while(itens.temProximo()) {
       String item = sc.proximo();
       processador.interpreta(item);
    }
  }
}

Passar um mock para a classe acima e consequentemente testá-la de maneira isolada ficou é fácil. A adoção dos testes de unidade deixa explícito o excesso de dependências (ou dependências implícitas escondidas).

Por fim, os testes precisam ser simples e curtos, limitando seu escopo; um teste muito grande ou complicado pode indicar que o método em questão possui muita responsabilidade.

Considere uma classe que é responsável por gerar uma nota fiscal a partir de uma fatura e disparar a mesma para o e-mail do cliente, assim como para um sistema SAP qualquer. Essa classe já possui as dependências bem explícitas:

public class GeradorDeNotaFiscal {
       private final Sap sap;
       private final EnviadorDeEmails enviador;

       public GeradorDeNotaFiscal(Sap sap, EnviadorDeEmails enviador) {
               this.sap = sap;
               this.enviador = enviador;
       }

       private NotaFiscal geraNotaFiscalAPartirDa(Fatura fatura) {
           // codigo de geracao da nota fiscal
       }

       public void gera(Fatura fatura) {
               NotaFiscal nf = geraNotaFiscalAPartirDa(fatura);

               sap.armazena(nf);
               enviador.envia(nf);
       }
}

Passar mocks para essa classe é fácil, já que é possível injetar todas as dependências nela. O problema é que, para criar testes para ela, o programador se preocuparia em testar se a nota fiscal foi gerada, se ela é enviada ao SAP e se ela é enviada para o cliente:

@Test public void deveGerarANf() { ... }
@Test public void deveArmazenarNfNoSap() { ... }
@Test public void deveEnviarNfParaOEmailDoCliente() { ... }

Perceba que essa classe tem responsabilidades demais: ela gera NF, envia para o SAP, envia para o cliente. Ao escrever esses testes, o programador perceberia que, em cada teste, ele estaria preocupado em testar uma responsabilidade da classe, sem se importar com a outra. No teste deveArmazenarNfNoSap, por exemplo, o programador seria obrigado a passar um stub da classe Email, mesmo não sendo o foco daquele teste. Isso torna a escrita do teste mais massante é um sinal de que a classe tem baixa coesão.

Portanto, se o seu design possue um alto acoplamento ou uma baixa coesão, será praticamente impossível escrever testes de unidade. Por esse mesmo motivo métodos estáticos, singletons, factories e estado global dificultam os testes de unidade.

Pensar e criar os testes antes do código também auxiliam no design. Usar Test-Driven Development força que a concentração do pensamento lógico foque nas responsabilidades de cada método, ao invés da exata implementação do mesmo.

Esse impacto no design é tão grande que muitos vão utilizar a sigla TDD para Test-Driven Design. Com TDD o programador é forçado a pensar em decisões de design antes do código de implementação, criando um maior desacoplamento, deixando mais claro suas necessidades.

O TDD, através dos testes de unidade e refatoração, possibilitam que o design apareça de uma maneira mais evolutiva, mas sem mágicas, sempre dependendo de conhecimento do desenvolvedor em relação a design e orientação a objetos.

Um exemplo desse tipo de abordagem é a tentativa de se testar uma constante, entre outros clássicos como a presença de uma anotação, métodos de delegação, getters e setters, etc. Supondo uma classe que armazena constantes de cartão de crédito e um possível teste de unidade para ela:

public class CartoesDeCreditoTest {
  @Test
  public void deveRelacionarVisaComOValor123() {
    assertEquals(123, CartoesDeCredito.VISA);
  }
}

public class CartoesDeCredito {
  public final static int VISA = 123;
  public final static int MASTERCARD = 456;
}

Repare que existe uma duplicação de dados entre o código de teste e o código de produção: o número 123. Quando o valor dessa constante mudar, você possui dois pontos de código para alterar. Ao fazer uma refatoração para remover essa duplicação, teremos um resultado como a seguir:

public class CartoesDeCreditoTest {
  @Test
  public void deveRelacionarVisaComOValor123() {
    assertEquals(CartoesDeCredito.VISA, CartoesDeCredito.VISA);
  }
}

Muitas vezes, o programador, acostumado a escrever testes de unidade para todo o código, acaba desenvolvendo testes sem utilidade: código que na realidade não testa nada. Naturalmente, o desenvolvedor não faria a refatoração acima, tal exemplo demonstra como um teste do genêro não traz valor, somente complexidade para nosso sistema.

Ou seja, em casos como o mostrado acima não há utilidade em escrever um teste de unidade para constantes. Ao fazer isso, o programador gera duplicação de dados entre a classe de teste e a de produção.

É importante testar constantes, mas no caso acima por exemplo, não através de testes de unidade: se ela representa um valor de um outro sistema, por exemplo, escreva um teste de integração.

No caso do cartão de crédito, suponha que a constante 123 seja o código do pagamento via cartão VISA no sistema do PayPal, portanto testamos a integração entre a aplicação e o sistema externo. Verifique se, ao passar o valor 123, o pagamento gerado foi um pagamento VISA.

@Test
public void deveEnviarCartaoVisaParaOPayPal() {
  Cobranca resultado = payPal.efetuaCobranca(valor, numeroDeUmCartaoVisa, CartoesDeCredito.VISA);

  assert(that(resultado.getStatus()).is(PayPal.APROVADO));
}

Em um exemplo mais elaborado, imagine agora o seguinte trecho de código abaixo que usa o Active Record do Rails para fazer um filtro:

def filtro(name)
  where("nome like %#{name}%")
end

def test_verifica_se_where_foi_invocado
  componente.should_receive(:where).with("nome like 'guilherme'")
  componente.filtro("guilherme")
end

# outra variação do mesmo teste:

def test_verifica_se_where_foi_invocado
  query = componente.filtro("guilherme")
  query[0].should == "nome like 'guilherme'"
end

Neste caso, uma vez que o método possui um corpo simples, uma invocação de uma função do Active Record, o teste abusa de mocks e é apenas uma mímica daquilo que o método executou. Ele garante somente que o programador digitou aquilo que ele esperava digitar. Testes como esse só indicam um problema no design do teste ou um problema no design do código.

No mundo Java é comum ver similares quando encontramos a utilização de Mocks ao extremo:

public void adiciona(Produto p) {
  this.session.save(p);
}

@Test
public void testSalvarEhInvocado() {
  Produto produto = new Produt();
  one(session).save(produto);
  dao.adiciona(produto);
}

Veja que o próprio nome do método diz que ele não serve pra nada: verifica se o salvar é invocado. Você quer testar o comportamento que essa classe terá sobre seu sistema e não se um determinado método foi invocado. A obviedade que o método está sendo invocado é trivial de ser notada e por isso mesmo não precisaria ser nosso foco no teste.

Mas alguns podem dizer: mas não preciso testar o Active Record, eu sei que ele funciona. Ou ainda, não preciso testar o Hibernate, eu sei que ele funciona. Sim, você não precisa testar o Active Record unitariamente pois ele já foi testado, mas existe a necessidade de testar a integração do seu código com o Active Record. No exemplo de uma query, sabemos que escrevemos uma query como desejávamos, mas ela está retornando aquilo que desejamos? E deixando de lado o resto? São essas perguntas que nosso teste precisa responder.

def test_deve_retornar_pessoas_que_tenham_parte_do_nome
  lista = executa_metodo_where("joão");

  lista.should_contain o_cidadao("João Gilberto")
end

O mesmo vale para queries em Java que utiliza JPA/Hibernate.

Para saber mais sobre teste e design: Kent Beck já discutia acoplamento tanto de dados quanto de código entre classes de teste e classes de produção. Isso é muitas vezes ignorado pelo programador. Imagine que você precise alterar muitos testes toda vez que fizer uma pequena alteração: é um indício de um design rígido, onde uma simples alteração propaga uma série de outras alterações.

Como regra geral, que possui suas excecões, não existe valor em um teste que é uma mímica daquilo que foi digitado e não de seus efeitos e retornos. Nesse caso, pense duas vezes antes de escrever esse teste e verifique se testar aquela classe de outra maneira (através de um teste de integração, por exemplo) não seria mais útil.

Também é natural surgir o desejo de mudança: a medida que nos especializamos nesse domínio, o modelo do negócio em nossa mente passa a ser diferente da visão inicial.

Um exemplo simples dessa mudança acontece quando em OO criamos um relacionamento bidirecional entre duas classes através de listas, como no exemplo a seguir:

// a representação de um cliente, funcionário etc
public class Pessoa {
  List<Conta> contas;
}

// a representação de uma conta bancária (poupança, corrente, investimento etc)
public class Conta {
  List<Pessoa> pessoas;
}

A primeira vista esse é o relacionamento entre as duas entidades mas em determinado momento notamos que na verdade a relação entre pessoa e conta é um Titular, que possue características próprias, como o contrato que ele como titular da conta assinou:

public class Pessoa {
  List<Titular> titularidades;
}
public class Conta {
  List<Titular> titulares;
}
public class Titular {
  Conta conta;
  Pessoa pessoa;
  // outras características de uma titularidade
}

Nesse caso o processo de refatoração envolve extrair uma classe que representa tal relação, um Titular: um exemplo simples que demonstra como em OO é comum a existência de classes para representar informações intangíveis.

Outras questões simples mas fundamentais para o bom design e legibilidade da aplicação estão ligados aos nomes que escolhemos, não só em relação ao nome da classe e de seus métodos. No exemplo acima, por uma escolha fraca no nome da variável membro conta e pessoa acabamos com um código que parece repetitivo e pouco descritivo:

  Pessoa pessoa;

Se em nosso sistema funcionários, gerentes, titulares e caixas são representados através de instâncias do tipo Pessoa, o mais adequado seria nomeá-los de acordo:

public class Titular {
  Conta conta;
  Pessoa cliente;
}

A tendência natural do desenvolvedor em linguagens que obrigam a declaração do tipo é criar variáveis com nome identicos ao tipo declarado, por ser um atalho das IDEs e mais simples de escrever. Mas tais alternativas, como visto, dizem pouco sobre a variável que está sendo acessada. Por esses motivos, é muito comum encontrar código como:

Cliente cliente = clienteDao.busca(13);
Pagamento pagamento = pagamentoDao.busca(15);
ProcessadorDePagamento processador =
                                new ProcessadorDePagamento();
processador.processa(cliente, pagamento);

Cliente, pagamento, processador: é somente desses três elementos que nosso domínio é composto? E nem mesmo Ruby foge disso, sendo comum encontrar:

cliente = Cliente.find_by_id 13
pagamento = Pagamento.find_by_id 15
processador = Processador.new
processador.processa cliente, pagamento

Três aparições de cliente, três de pagamento, quatro de processador. Aqui existe uma visão distorcida de que variáveis são somente aquilo que o tipo descreve: um cliente, um pagamento, um processador. Na verdade elas referenciam instâncias específicas e especializadas de um tipo determinado. Só faria sentido chamar o cliente 13 de cliente se ele é o único cliente, um singleton. Especialize o nome de suas variáveis e crie um código mais legível:

Cliente devedor = clientes.busca(13);
Pagamento fatura = pagamentos.busca(15);
ProcessadorDePagamento mensalidade =
                            new ProcessadorDePagamento();
mensalidade.cobra(devedor, fatura);

O mesmo pode ser refletido no exemplo de Ruby. E como trabalharemos nossos repositórios para permitir uma maior legibilidade do código?

Pessoa pessoa = ...;
List<Conta> contas = dao.contasDe(pessoa);

Note como por causa da escolha do nome da variável pessoa fomos obrigados a colocar algo mais descritivo no método. Caso a variável possua um nome mais adequado, teríamos então:

Pessoa cliente = ...;
List<Conta> contas = dao.contasDe(cliente);

Modificando nossa classe Conta para adicionar o gerente e o subgerente temos novamente o sentido das variáveis descrito não só pelo seu tipo, mas também pelo seu nome:

public class Conta {
  List<Titular> titulares;
  Pessoa gerente;
  Pessoa subgerente;
}

Nesse instante a query ficaria mais complexa pois existem dois relacionamentos distintos com pessoa, requerendo a criação de uma DSL interna para query. No exemplo a seguir usamos um builder para facilitar a construção da query:

Pessoa gerente = ...;
Pessoa subgerente = ...;
List<Conta> contas =
               dao.comGerenteESubgerente
                            (gerente, subgerente):

Essa é a abordagem que o jbehave 3.2 e o selenium utilizam, onde acabamos por ter uma sintaxe muito longa e repetitiva.

Retomando o problema do nome das variáveis, que pode ser resolvido com outra refatoração de rename: o código da terceira linha é mais descritivo que o anterior:

Pessoa gerente = ...;
Pessoa subgerente = ...;
List<Conta> contas =
               dao.comGerente(gerente)
                    .comSubgerente(subgerente):

Em linguagens onde mapas podem ser representados através de literais, o ruído sintático é baixo e permite que seja escrito código como a seguir em Ruby:

gerente = ...
subgerente = ...
contas = Conta.com
              :gerente => gerente, :subgerente => subgerente

Novamente, a refatoração aqui é fundamental:

principal = ...
secundario = ...
contas = Conta.com
              :gerente => principal, :subgerente => secundario

A escolha dos nomes de nossas classes influencia o design e legibilidade de nosso código direta e indiretamente, primeiro pela declaração das variáveis e a nossa visão do domínio. Depois pelas consequências que o mesmo possui na escolha dos nomes das variáveis e métodos, que permitem um design mais ou menos legível.

Essa escolha é tão importante quanto o resto de seu design para facilitar a compreensão do que seu domínio é e qual o problema que está tentando atacar. Na próxima vez que for declarar uma variável com o mesmo nome que o tipo, pense duas vezes.

O maior problema com o GenericDAO é que não necessariamente todas as operações fazem sentido para uma determinada classe. Daí o que fazer se, por exemplo, não faz sentido excluir um pagamento?

public class PagamentoDAO
          extends GenericDAO<Pagamento> {

     @Override
     public void excluir(Pagamento pagamento) {
         throw new UnsupportedOperationException();
     }
}

Não parece uma solução muito elegante, mas é um dos únicos jeitos de proibir uma operação declarada na classe mãe, e ainda assim, só funciona em tempo de execução. Esse é um dos principais motivos para muitos não gostarem de usar o GenericDAO e preferirem usar composição ao invés de herança. Mas como fazer para não repetir o código trivial das operações do CRUD?

Um dos jeitos é usar uma outra abstração de persistência de objetos: o Repository. Com o Repository, temos um lugar onde podemos guardar e buscar por objetos, não importando como fazemos isso. O DAO já está muito ligado com armazenamento em banco de dados, e foi criado quando as operações do BD eram muito trabalhosas (em especial no JDBC).

E como juntar o Repository com o GenericDAO? O Repository pode ser definido, por exemplo, como uma interface, e aí podemos fazer o seguinte: se, para um pagamento, faz sentido apenas salvar e listar, mas não excluir, então criamos a interface:

public interface PagamentoRepository {
    void salva(Pagamento pagamento);
    Pagamento busca(Long id);
    List<Pagamento> lista();
}

E usamos o GenericDAO como implementação dessa interface:

class PagamentoDAO
          extends GenericDAO<Pagamento>
          implements PagamentoRepository {
   // implementacao extra
}

E no nosso código de domínio “nunca” referenciaremos o PagamentoDAO, apenas o PagamentoRepository, assim mesmo que a implementação saiba fazer mais coisas, a interface só expõe as operações suportadas.

Se você usa Injeção de Dependências e algum framework que a suporta (como o VRaptor, Spring ou Java EE6), você pode deixar os DAOs apenas como infraestrutura, e usar os Repositories como interfaces públicas da sua aplicação:

public class PagamentoController {
    public PagamentoController(PagamentoRepository repository) {
         this.repository = repository;
    }

    public void salva(Pagamento pagamento) {
         // validações e outras regras
         repository.salva(pagamento);
    }
}

Ainda poderíamos melhorar o nome do nosso repositório para BaseDePagamentos, ContasAPagar ou ainda Pagamentos, evitando usar sufixos nas classes. Usando abstrações e padrões simples conseguimos evitar repetição de código sem perder a semântica e restrições das nossas classes de modelo, além de esconder detalhes de implementação.

Durante o atual processo de revisão do livro de Arquitetura e Design de Software, discussões apareceram sobre o termo arquiteto. Antes de definir o que faz um arquiteto, há o termo arquitetura.

Quem é o arquiteto? Aquele que senta sozinho e toma todas as grandes decisões?

O que é a arquitetura de uma aplicação?
Uma pergunta difícil de responder. Entre as definições mais antigas, Roy Fielding possui um bom texto no primeiro capítulo de sua dissertação de doutorado. O Instituto de Engenharia de Software da Universidade de Carnegie Mellon apresenta diferentes definições, algumas clássicas e bastante conhecidas, como “arquitetura é a estrutura do sistema, composta de componentes, as propriedades que são visíveis externamente desses componentes e o relacionamento entre eles“.

Nas palavras de Martin Fowler, “o termo arquitetura envolve a noção dos principais elementos do sistema, as peças que são difíceis de mudar. Uma fundação na qual o resto precisa ser construído“. Fowler reformula sua definição de arquitetura e a define como “as peças que as pessoas acham que é difícil de mudar“. No mesmo artigo Ralph Johnson, do GoF, diz que arquitetura “é o conjunto de decisões de design que gostaríamos de ter feito no começo do projeto” e termina com uma definição mais abrangente: “arquitetura é tudo aquilo que importa“. Com tantas definições, talvez seja mais fácil diferenciarmos design de arquitetura.

Qual é a diferença de design e arquitetura de software?
Aqui também temos uma resposta clássica na literatura: a arquitetura é responsável pelos requisitos não-funcionais, e o design pelos funcionais. Mas parece que essa distinção não é tão clara assim para muitos outros autores.

Neal Ford apresenta uma distinção simples, realçando que o design é feito em cima do que foi decidido pela arquitetura, e por isso o que faz parte da arquitetura é mais difícil de mudar. Devemos minimizar as peças que dificultam mudanças do nosso design, mas é impossível eliminar todas, além de que flexibilidade sempre vem a um custo de complexidade.

É difícil criar um distinção maior entre os dois. No livro Patterns of Enterprise Application Architecture, Fowler diz que “alguns dos padrões nesse livro podem ser chamados arquiteturais, já que representam decisões importantes sobre essas partes; outros são mais sobre design e te ajudam a implementar essa arquitetura. Eu não faço nenhuma tentativa forte de separar esses dois, já que é o que é arquitetural ou não é subjetivo“.

O arquiteto deve saber programar na plataforma em questão?
Sem dúvida. Cada vez mais vemos que o design e a implementação devem ser trabalhados juntos. A imagem de um arquiteto distante sem profundo conhecimento técnico que apenas toma as grandes decisões ficou pra trás: conhecimento técnico e a capacidade de liderança são as características fundamentais.

Mais do que querer ser o poderoso arquiteto que apenas despacha ordens e toma todas as grandes decisões, cada vez mais enxergamos que o caminho é ser o líder que incentiva essa tomada de decisão, além de ser um exímio programador. Parafraseando mais uma vez Martin Fowler, “…o arquiteto deve ser como um guia… que é um experiente e capacitado membro da equipe que ensina aos outros a melhor se virarem, ainda assim ele está sempre lá para as partes mais complicadas“.

Vale lembrar que precisamos de mais de 10 mil horas, ou 10 anos, para dominar uma linguagem.