Diferença entre os patterns PO, POJO, BO, DTO e VO

Uma pequena lembrança sobre o conceito de orientação a objetos

Diariamente, inúmeros programadores em torno do mundo lidam com diversos problemas que “devem” ser resolvidos através de sua implementação em uma linguagem de programação. Na grande maioria das vezes essa mesma necessidade é exigida com demasiada rapidez e pouquíssimo prazo.

Para tanto, os profissionais desenvolvedores de linguagens que fazem uso do conceito de orientação a objetos criaram, a partir de tais necessidades, os padrões de projeto. Padrões de projeto são extremamente usados, questionados, reanalisados e exigidos por inúmeras empresas do ramo de Tecnologia da Informação (especialmente as que desenvolvem softwares - fábricas). O conceito é tão famoso que já foi usado para resolver problemas fora do ramo de TI, com estratégias de implementação atuante, uma vez que o modelo remete ao mundo real com exemplos de objetos agindo e sendo tais como no cotidiano do negócio envolvido.

Dentre tantos padrões existentes, alguns são muito famosos pela genialidade de sua criação enquanto outros deixam muitos usuários confusos quanto a como e onde usar e as suas diferenças em relação a outros padrões semelhantes. O pattern DAO, por exemplo, é muito conhecido e usado no mundo de desenvolvimento de software em Orientação a Objetos, entretanto muitos confundem a real diferença entre este padrão e o padrão Repository.

Neste artigo serão apresentadas as diferenças básicas entre os padrões PO (Persistent Object), POJO (Plain Old Java Object), BO (Business Object), DTO (Data Transfer Object) e finalmente o VO (Value Object). Estes padrões geram muita confusão entre os desenvolvedores e por muitas vezes são tidos como repetidos ou iguais, tornando assim seu uso devido indiferente.

Persistent Object – PO

Esse padrão é muito usado em conjunto com o framework de persistência ORM Hibernate. Representa apenas um objeto de persistência simples com atributos, métodos de recuperação e setagem, muito semelhante ao VO ou TO (Transfer Object), porém sem nenhuma referência a códigos de transação com o banco de dados.

Data Transfer Object – DTO

O próprio nome já diz muito: um objeto simples usado para transferir dados de um local a outro na aplicação, sem lógica de negócios em seus objetos e comumente associado à transferência de dados entre uma camada de visão (view layer) e outra de persistência dos dados (model layer). Muito frequentemente você verá esse padrão sendo usado em conjunto com um DAO. Veja na Figura 2 um exemplo claro dessa representação e desse conjunto entre os dois padrões.

Esse padrão também é bastante usado quando não se deseja expor a camada de persistência, porém é preciso que sejam exibidos os mesmos dados na camada de apresentação. Por exemplo, considere uma tela de uma aplicação que necessite listar os dados de 10 pessoas cadastradas em uma tabela. Para acessar estes dados, a camada de persistência assim o faz com a listagem configurada em um ArrayList de 10 PO’s (vide padrão acima). Para passar esses valores à tela, a mesma lista antes tem de ser convertida para uma lista de DTO’s com mesmos atributos e métodos get’s/set’s. Tudo isso porque a mesma aplicação faz uso do JPA, por exemplo, ou Hibernate e os mesmos frameworks não permitem que os dados tidos como “lazy (preguiçosos)” perdurem até depois de a conexão ter sido fechada. Por tal razão a conversão se faz necessária e assim os dados poderão fazer o trajeto sem serem perdidos ou sem que nenhum erro de conexão venha a acontecer.

Observação: os padrões de projeto também não devem ser usados em detrimento do ambiente onde se está executando o mesmo projeto, a ideia é que eles sejam abstratos o suficiente para se adaptar, porém você será o autor principal disso, então não desconsidere o ambiente na hora de pensar em todos os cenários adaptáveis.

Plain Old Java Object – POJO

Em setembro de 2000, Martin Fowler, Rebecca Parsons e Josh MacKenzie cunharam o novo termo para designar um objeto sem grande valor dentro do modelo de classes de um projeto, an ordinary Java Object. Na mesma ocasião os mesmos disseram:

“Nós nos perguntamos por que as pessoas eram tão contra o uso de objetos regulares em seus sistemas e concluímos que era porque faltava um nome fantasia para os objetos simples. Assim, demos-lhes um, e caiu muito bem.”

Resumindo, é um termo usado para denotar um objeto Java que não segue nenhum dos conceitos principais dos modelos de objetos Java, convenções e frameworks.

Os POJO’s conseguem, inclusive, ser convertidos em outros padrões já citados, como:

1. POJO Persistence -> PO
2. POJO Transmission Process -> DTO
3. POJO como presentation layer -> VO

Business Object – BO

Um objeto de negócios é um tipo de uma entidade inteligível sendo e agindo como um ator dentro da camada de negócio em uma arquitetura de n camadas orientado a objeto.

Basicamente sua função é encapsular a lógica de negócios para um objeto (que pode incluir vários POs e geralmente precisam de um BO em um PO). Um PO pode ser um BO no final das contas, mas antes precisa ser convertido para tal.

Há três conceitos principais sobre BO:

1. Contém apenas as propriedades do objeto de negócio;
2. Contém apenas os métodos de negócio;
3. Ambos.

Durante o uso efetivo, o conceito do que é correto não é importante, a chave é apropriada para a aplicação prática em suas próprias necessidades de projeto.

Value Object – VO

Esse padrão é um pouco confuso. Segundo a Wikipédia, um Objeto de valor “é um pequeno objeto que representa uma entidade simples, cuja igualdade não é baseada em identidade: ou seja, dois objetos de valor são iguais quando têm o mesmo valor, não necessariamente sendo o mesmo objeto”.

Isso parece confuso quando pensamos em objetos Java atuando como POJOs simples. Definições a parte, esse padrão até hoje sofre alterações em suas explicações. Alguns o definem de uma forma outros a sua maneira, etc. É um objeto usado basicamente para exibir dados na camada de apresentação. Uma noção formal do que é de fato um “value object” pode ser encontrada na JEP 169 (Vide links).