Muito tem se falado em POJOs (Plain Old Java Objects), boas e más coisas. As boas coisas geralmente mencionam como é mais fácil desenvolver sem utilizar parafernalhas como EJB 2.x e sobre o poder que utilizar OO pura te dá. As coisas ruins falam sobre como a comunidade Java é formada por um bando de idiotas que acaba de descobrir que existe vida além de frameworks e dão para este conceito um nome estúpido.
Justificando a ‘abordagem POJO’, vamos tentar entender o porque do hype em cima de POJOs. Antes de mais nada vamos a uma definição:
Um POJO é um objeto java normal que não implementa nenhuma interface nem estende nenhuma classe específica de um framework.
Exemplificando, isso é um POJO:
public class Venda{
private List- vendas = new ArrayList
- ();
public void adicionarItem(Item i){
vendas.add(i);
}
…
}
Esta classe não depende de nenhum framework, ela lida apenas com os objetos do domínio em questão.
Mas isto não é um POJO:
public class AdicionarVendaServlet extends HttpServlet {
...
public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
venda.add(daoItens.get(req.getparameter("item"));
}
}
Porque para criar um Servlet você precisa estender uma classe do framework de Servlets.
E porque dar um nome para classes Java normais? Bem, segundo Fowler, um dos autores do termo, basicamente o termo surgiu como um vocabulário comum e cool para se referir a esta técnica. É aquela história de vocabulário comum que falamos outro dia.
Um sistema baseado em POJOs utilizando Camadas, DIP e outras técnicas para eliminar a dependência de frameworks e outras classes de infra-estrutura é bem interessante. Na revista Mundo Java deste mês há um artigo introdutório meu falando sobre como você pode aplicar POJOs no desenvolvimento do seu Domain Model, utilizando Patterns específicos.
Uma coisa que andei pensando estes dias é uma lei que restrinja ainda mais o acoplamento de POJOs na Camada de Negócios com a infra-estrutura. Taí o que eu chamo de Strict POJOs:
Um POJO só pode se relacionar diretamente com outro POJO ou com POJIs.
POJI são Plain Old java Interfaces, é o mesmo conceito de POJO aplicado a interfaces. A idéia é baseada no DIP (Dependency Inversion Principle, mais detalhes na revista) e a sua classe de infra-estrutura deve implementar uma POJI para poder ser utilizada por seu POJO. Confuso?
Exemplo:
Imagine que temos uma classe Usuario que precisa acessa o banco de dados para consultar seus grupos. Como é uma classe de negócio ela não deve nem pensar em encostar em hibernate, JDBC, JDO ou o que estiver utilizando. Normalmente alguém faria um DAO acessar o banco de dados e a classe de negócios utilizar o DAO. Bem, DAO é uma classe de infra-estrutura e para aplicarmos nosso conceito de Strict POJOs o Usuario não pode conversar com ela. E agora?
Abstraímos o banco de dados seguindo o padrão Repository:
public interface RepositorioGrupos{
public List listarGrupos(Usuario u);
}
Esta interface é uma POJI. Agora faremos nosso usuário lidar com esta interface ao invés de com o DAO:
public class Usuario{
private RepositorioGrupos repositorio=null;
/** Checa se o usuário pertence a um dado grupo */
public boolean pertenceA(Grupo g){
List meusGrupos = repositorio.listarGrupos(this);
boolean pertence = meusGrupos.contains(grupo);
return pertence;
}
}
E faremos o DAO implementar a interface RepositorioGrupos (essa parte foca para você).
A vantagem desta abordagem é separar completamente a infra-estrutura da sua aplicação. Se você trabalha com um processo onde se produzem diagramas antes de codificar, isto permite que você crie diagramas muito mais reais, já que neles você não precisa se preocupar com bancos de dados e etc. O uso de um framework como Spring ou Java EE 5.0 ajuda muito já que você não precisaria nem mesmo isntanciar seus objetos.
A idéia básica é que você deve manter seus objetos de negócio isolados de tudo que não seja regra de negócio.
Bom, espero que gostem do artigo ;)
NOTA: Os arquivos estarão disponíveis até o fim da semana. Deixe seu email aqui nos comentários e você será avisado.
