RFWVO

Todo a estrutura do RFW é baseada na manipulação dos objetos do tipo RFWVO. Entender a base da estrutura do VO e seu funcionamento é o primeiro passo para desenvolver bem no RFW.

Introdução aos Objetos de Dados dos Patterns Java

O RFWVO é um Value Object: O Value Object (VO) era um termo inicialmente utilizado para indicar um objeto capaz de guardar uma pequena quantidade de informação. Como o objeto/classe Integer ou String do Java. Além disso, um VO deveria ser imutável. Toda vez que seu dado precisasse ser alterado, o objeto deveria ser descartado e um novo construído, exatamente como as classes do Java citadas. Já um Data Transport Object - O Data Transfer Object (DTO) é o objeto capaz de carregar as informações através da rede, ou mesmo entre as camadas (sendo que as camadas podem estar em diferentes máquinas). Ou seja, o DTO é o objeto que carrega os VOs entre as camadas ou sistema distintos. Os DTO também são conhecidos só por TO (Transfer Objects).

Com o tempo a utilização do termo VO passou a indicar objetos maiores capaz de guardar uma coleção de informações/atributos de um determinado objeto, bem como a serem transmitidos entre as camadas e rede. Ou seja, popularmente chama-se de VO os objetos acima chamados de DTO.

Já o Java Bean tem as seguintes regras:

• Conter um construtor publico padrão - isto é, um construtor que não receba nenhum parâmetro.

  O objetivo dessa regra é permitir que os frameworks possam instanciar o objeto facilmente, sem necessariamente conhece o objeto e saber que dados passar no construtor.

• Seus atributos devem ser acessíveis através de métodos GET e SET. E preferencialmente ter seus atributos privados para evitar um acesso direto.
• Sua classe deve ser serializável, isto é, implementar ou estender alguma classe que implemente a interface 'Serializable' do java.

  Isso permite que o objeto seja convertido em vários outros tipos de estrutura (como XML) e salvos ou transmitidos para outros plataformas, frameworks, computadores, etc. e ser retornado em um objeto.

A Mudança e o RFW

No RFW chamamos o objeto de VO e juntamos todas as funcionalidade em um objeto único! Assim, o VO do RFW é:

• o objeto capaz de representar uma pessoa, uma venda, uma nota, um produto e assim por diante (como um VO ou Java Bean);
• é utilizado e transferido desde a camada de persistência até a camada de apresentação (como o DTO);
• tem as mesmas obrigações que o Java Bean (de construtor e acesso dos atributos por GET e SET, devendo estes métodos seguir a convenção de nomes definidos pela Sun);
• devem obrigatoriamente estender a classe RFWVO.

As vantagens de ter um único objeto, primeiro é não ter que implementar várias classes (um Bean, Um VO, um TO, etc) que representam a mesma coisa. Ganhamos no tempo de desenvolvimento, manutenção do objeto e de não ter que criar "conversores" que passam os dados de um objeto para outro.

As desvantagens é que passamos a ter limitações na criação dos objetos, como por exemplo, sendo o mesmo objeto usado em toda a aplicação, o objeto não pode simplesmente ganhar atributos por ser conveniente para a camada de apresentação ou para a camada de persistência. Em resumo, um RFWVO deve conter apenas os atributos que realmente descrevem o objeto e nunca atributos convenientes ou temporários para exibição ou de processamento. (Nestes casos recomenda-se a criação de outro BEAN que encapsule o VO).

O Atributo Fixo ID

Uma das características do RFWVO é já ter o atributo ID definido. O que faz com que todos os VO filhos ganhem o mesmo atributo ID. Note que estou falando de ter os métodos getID() e setID(), não o valor de ID.

Esse atributo ID funciona no sistema da mesma maneira que a Primary Key de um tabela de banco de dados. Na verdade, o ID é mesmo gerado pela camada de persistência e é utilizado para identificar o objeto no banco de dados. Na parte de Persistência (RFWDAO) esse tópico será melhor abordado.

Já no sistema, o ID do objeto tem algumas funcionalidade:

• Para uma mesma classe de VO, o mesmo ID indica o mesmo objeto;
• IDs diferentes indicam objetos diferentes;
• ID nulo indica um objeto que nunca foi persistido.

O ID Nunca Pode ser Alterado O ID de um objeto é criado pela camada de persistência, e depois será utilizado para identificar o objeto quando ele retornar para ser salvo. Trocar o ID fará com que a camada de persistência interprete como sendo outro objeto. O ID é único e intransferível. Depois que foi registrado (no caso depois que foi persistido a primeira vez) ele nunca mais se altera até a morte (exclusão do objeto).

O Clone Recursivo

Os objetos do RFW implementam a interface 'Cloneable' do java.

Mas mais do que isso, ela fornece método para Clone Recursivo. O que isso faz? Enquanto o clone padrão do Java cria um novo objeto pai mas deixa todas as referências dos sub-objetos apontando para os mesmos objetos em memória do objeto original. O Clone Recursivo:

• faz um clone completo do objeto criando completamente outras instâncias para todos os sub-objetos do VO.
• duplica listas, hashs, arrays, e outros objetos de coleção, duplicando também seus conteúdos.
• É capaz de detectar "loop", ou referências cíclicas entre os objetos e as recria mantendo as mesmas referências mas com objetos completamente novos. Os únicos objetos reaproveitados são os objetos imutáveis, como String, Integer, Long, BigDecimal, etc..

Limitação do Clone Recursivo O método conhece alguns objetos de coleção mais utilizados no RFW, como ArrayList, LinkedList, HashMap, etc.. Caso seja utilizado algum tipo de objeto diferente dos comumente utilizados, o método precisa ser verificado e talvez ter o suporte à esses objetos acrescentado.

O Paradoxo do Equals

O RFWVO e todos os seus descendentes devem manter a implementação do equals inalterada para utilizar todos os serviços do RFW. Muitos dos serviços que o RFW oferece utiliza o a implementação do equals padrão (que verifica se é o mesmo objeto na memória) para garantir que não estamos em uma iteração infinita quando os VOs tem uma referência cíclica.

Em algumas situações esse equals precisaria de uma implementação diferente. Pois o equals implementado só reconhece se for o mesmo objeto na memória, já em alguns momentos temos instâncias diferentes que precisamos identificar se é o mesmo objeto.

Para casos como esse a solução é encapsular o objeto e neste implementamos o Equals da maneira como achamos conveniente. Como por exemplo comparando a classe e o ID dos objeto. Para essa solução conheça o GhostVO (GVO).

Para objetos não persistidos em banco de dados o equals precisa ser mais elaborado já que não teremos o ID definido.