Value Object

Este texto foi atualizado e doado ao projeto Code Design World. Leia a versão mais atualizada.

VO significa …

VO é a abreviação de Value Object. O problema é que Value Object significa muitas coisas.

Value Object em EJB

Quando a tecnologia Enterprise JavaBeans (EJB) foi lançada, ela assumia que os métodos eram invocados remotamente. Isso significava que se o método setNome() da entidade Customer fosse invocada na máquina cliente a invocação aconteceria na realidade na máquina servidor. A comunicação usando um protocolo sobre IIOP tornava todos os EJB transparentemente remotos.
O problema é que se o bean tivesse 10 campos ( ou mais) aconteceriam 10 invocações remotas ( ou mais). Rápidamente isso se mostrou um problema já que mesmo em uma rede veloz isso é um problema de eficiencia.
A solução para isto foi criar um objeto auxiliar onde todos os modificadores eram invocados (localmente) e depois o objeto seria enviado ao bean de uma só vez. Uma só chamada remota faria a atribuição de todos os atributos. Este objecto de transferência rápidamente se tornou um padrão; o TransferObject.

À medida que mais e mais pessoas usavam esta gambiarra do EJB ficou evidente que os Entity Beans tinham um design falho. Duas respostas foram encontradas para este problema:

1. Minimizar a comunicação remota quando o bean e o seu cliente estavam na mesma JVM. Isso levou à introdução das interfaces locais.
2. Adbicar de usar a tecnologia EJB. Algumas soluções tecnicas apareceram – como o framework Spring – junto com alternativas teoricas como o Domain Driven Development (DDD).

O objecto de transferência rápidamente ganhou outros nomes: DataTransferObject (DTO) e Value Object (VO). Tudo sinónimos.

Value Object em DDD

Martin Fowler elaborou um catálogo de padrões uteis a quem constrói aplicações empresariais. Um desses padrões considerava que é muitas vezes util encapsular valores em objetos em vez de usar tipos primitivos ou objetos padrão ( como Map, por exemplo). Este padrão parte da ideia de que cada objeto desta classe representa um valor diferente de entre um conjunto possivel Exemplos simples deste tipo de objeto podem ser encontrado no próprio JDK: Integer, BigDecimal, Date e até String. Fowler chamou a este padrão Value Object.
A ideia agradou e encontrou adeptos na filosofia DDD. Objetos como Quantity e Money nascem diretamente da aplicação deste padrão.

Value Object representa,portanto, dois padrões diferentes. Para quem conhece o padrão descrito por Fowler, o padrão original derivado do uso de EJB começou a ser chamado simplesmente DTO ou TO deixando a sigla VO para o novo padrão. Claro que esta destinção só é válida para quem conhece os dois padrões. Caso contrário a ambiguidade é um empecilho. O padrão Value Object a que me refiro é aquele descrito por Fowler. Um objeto que representa um valor.

Objecto de Valor

A ideia é simples. É muitas vezes interessante encapsular um valor num objeto e prover métodos para manipular esse valor de forma implicita. Este objetos são bastante uteis porque contêm muita logica de dominio relativo ao valor que representam e ao mesmo tempo nos liberam de saber essa logica ou de a recordar cada vez que é necessário. Por exemplo, um objecto que represente numeros complexos implementará todas as operações com numeros complexos de forma que o objeto seja usado como um numero. Temos que saber como multiplicar e dividir numeros complexos, mas apenas precisamos nos lembrar disso durante a implementação. Depois podemos usar o objetos inumeras vezes aumentado a reusabilidade do codigo e simplicifando as aplicações de dependem da manipulação de numeros complexos. Em diferentes dominios existem diferentes objetos de valor. Em geral, um objeto de valor pode ter um numero ilimitado de atributos. O que interessa é dois objetos da mesma classe são iguais se os estados deles são iguais.

As vantagens deste padrão são:

• Fornecer tipagem mais forte – É muito melhor usar BigDecimal do que String na assinatura de um método. Ou Date em vez de três inteiros.
• Fornecer métodos de manipulação do valor de forma coesa – Se o objeto representa um numero porque não ter métodos plus() ou mutliply()? Este métodos se fornam aceleradores já que são usado inumeras vezes em vez de código que transforma o valor em algo manipulável e faz a operação e converte de volta. Repetir isso sempre que é necessário torna o codigo poluido e de dificil manutenção ( já para não dizer sensivel a erros)

Propriedades

Não existe uma implementação especifica para o padrão Value Object já que dependente muito do tipo de valor em causa e das regras relativas a esse valor que queremos implementar. Contudo existem algumas propriedades de uma implementa deste padrão.

Imutabilidade

Uma das caracteristicas essenciais do padrão Value Object é a imutabildiade. Isto significa que o estado do objeto não pode ser alterado. Para criar um objeto que representa outro valor não podemos reaproveitar o objeto anterior; temos que criar um novo. String, Date e todos os Number são exemplos disto. Porque o objeto é imutável a sua implementação é mais simples já que não tem que controlar alterações do estado do objeto.

Métodos de Criação

Embora o uso de construtores seja simples o seu uso é pouco fluente. A obrigação de escrever new a todo o momento, além de chato, revela que ha pouca margem para alterações das assinaturas dos construtores.

Por outro lado como estamos usando um objeto para encapsular uma valor e suas regras é comum ter que converter de e para o objeto a partir de outros tipos. Mais uma vez, Integer é um exemplo disto com a conversão de e para String. E String é exemplo na conversão para array de char ou array de byte.

É comum portanto que a classe forneça um conjunto de métodos destinados a cria o objeto com base em outros tipos de informação.

Licença

Sérgio Taborda Este trabalho é licenciado sob a Licença Creative Commons Atribuição-Uso Não-Comercial-Não a obras derivadas 3.0 Genérica .