VRaptor 3 - Revista Java Magazine 94 - Parte 2

O desenvolvimento web tomou conta do mercado deixando as outras modalidades para trás. Junto com esta evolução vieram os frameworks e suas soluções que tornam a cada dia o desenvolvedor mais produtivo. Pensando em produtividade, conhecemos no primeiro artigo da série um framework que ajuda o desenvolvedor a melhorar sua performance. Assim, vimos como configurar o VRaptor 3, conhecemos suas principais características e como desenvolver um sistema baseado em CRUDs.

Na segunda parte, vamos aprender como tornar o código mais eficiente e reutilizável com o uso de herança e classes genéricas. Além disso, também será reduzido o acoplamento trabalhando com o sistema voltado a interfaces, onde o desenvolvedor passará a se preocupar com o que o código faz e não mais em como ele faz.

Até este momento nos preocupamos bastante com a codificação feita para o servidor, mas agora vamos dar mais ênfase à parte visual do sistema, que também é de suma importância. Lembre-se que “o sucesso de uma aplicação depende tanto de um modelo que funcione quanto de uma interface que seja amigável para o usuário final”. Por isso trabalharemos nesta camada tirando proveito dos templates para o reaproveitamento de código e a inclusão da biblioteca visual jQuery UI com alguns de seus componentes.

Herança

O termo herança, conhecido também fora da área de tecnologia, diz respeito a alguma característica herdada de alguém que já a possui. Na programação usamos herança para obtermos códigos que são comuns a mais de uma classe, como por exemplo, o atribute id que cada modelo da aplicação obrigatoriamente deve possuir. Desta forma será criada uma classe abstrata para manter esse atributo que poderá ser herdado por outras classes. Este atributo também já estará anotado com as configurações da JPA e o seu get() e set(), aumentando com isso o reaproveitamento do código, como pode ser visto na Listagem 1.

Listagem 1. AbstractEntity: entidade herdada por todas as outras entidades.

  @MappedSuperclass
  public class AbstractEntity {
   
    @Id
    @GeneratedValue
    private Long id;
   
    // get e set
   
  } 

Esta classe servirá de base para todos os modelos do sistema. Logo, devemos fazer com que os modelos herdem essa classe. Assim, o atributo id e seus respectivos get() e set() poderão ser removidos de todos os modelos, pois agora iremos recebê-los da entidade AbstractEntity através da herança. Veja um exemplo a seguir com a entidade Filme, mas que deverá ser feito com todas as outras entidades do sistema:

  public class Filme extends AbstractEntity {
   
  } 

É preciso observar que a entidade abstrata só servirá para herança, por isso, no lugar do @Entity, esta classe será anotada com @MappedSuperclass. Essa anotação indica para o Hibernate que a classe não será uma entidade que terá uma representação no banco em forma de tabela, sendo apenas uma superclasse.

Nos próximos tópicos vamos criar uma classe que também será reutilizada, assim como a que acabamos de implementar, e servirá para manter os métodos do CRUD que são utilizados em todo o sistema.

Classes genéricas

A classe genérica é aquela que não recebe ou manipula um tipo exato, ou seja, ela tem a capacidade de trabalhar com vários tipos de classes diferentes. O nosso sistema possuirá a classe GenericBusiness, que será a base que manterá o CRUD. Esta classe não irá manipular um modelo específico, mas sim qualquer modelo que indicarmos, por isso ela é genérica. Assim, todas as outras classes de negócios que dependam de alguma ação do CRUD deverá herdá-la para obter estes métodos prontos. No código a seguir temos um trecho dessa classe genérica que em sua declaração recebe o tipo do modelo a ser manipulado:

  public abstract class GenericBusiness<T extends AbstractEntity> {
   
    protected EntityManager manager;
    protected Class<T> clazz;
   
    ...
  } 

Nesta classe foi recebido um argumento genérico (T) para indicar qual entidade será tratada no momento de utilizá-la. Veja que só são aceitas classes que estendem AbstractEntity, ou seja, deve ser uma entidade que obrigatoriamente tenha um ID.

A classe GenericBusiness precisará do EntityManager e de um Class, que servirá para manter o tipo da classe recebido através do argumento genérico T. Esta classe a ser manipulada será capturada no construtor da classe genérica, como mostra a Listagem 2.

Listagem 2. GenericBusiness: classe genérica que mantém o CRUD do sistema.

  protected GenericBusiness(EntityManager manager) {
    this.manager = manager;
    this.clazz = (Class<T>)
      ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
  } 

No construtor é recuperado o tipo da classe contido no argumento T. Através da classe atual, GenericBusiness, o tipo genérico é recuperado e convertido para o tipo parametrizado. Com isso o método getActualTypeArguments() recupera uma lista de argumentos e devolve apenas o primeiro por meio de seu índice [0], que é exatamente o tipo genérico. Por fim, este tipo genérico é convertido em um Class para que possamos saber qual classe a nossa classe genérica irá manipular. Quanto ao manager, continua com a sua injeção normalmente, porém não iremos mais injetá-lo em cada camada de negócios, pois ele também será herdado.