Por que eu devo ler este artigo: Neste artigo iremos tratar de um assunto muito importante e interessante para os desenvolvedores de sistemas corporativos feito em Java: A criação de Beans dinâmicos.
A maioria de nossos aplicativos representam nada mais, nada menos do que o modelo de nossa base de dados, incluindo é claro, toda a lógica de negócio. Porém, podemos perceber que os nossos objetos (ou modelos) de negócio muitas vezes se encontram amarrados conforme uma tabela e seus atributos em um banco de dados, tornando-os, “nada dinâmicos”.
Essa é uma forma errada de se programar? É lógico que não! A muitos anos desenvolvemos desta maneira, tanto é que “aprendemos” a programar desta maneira, refletindo no código a “aparência” da tabela. Isto já é de praxe, tanto é que várias empresas e corporações trabalham (e muito bem) desta maneira. Essa situação se encaixa muito bem quando desenvolvemos algo pensando em um cliente específico. Mas, e se pretendemos desenvolver um produto visando a usabilidade do mesmo em empresas diferentes, o que fazer? Temos que aprender com o tempo, melhorar nossa estrutura e até mesmo o pensamento para que nosso sistema/aplicativo/módulo seja um tanto quanto flexível para os nossos clientes.
Vamos imaginar o seguinte cenário onde o nosso cliente necessita que vários campos sejam atribuídos para um cadastro. Vejam através de um fluxo de processo, o trabalho que teremos para que seja implementado um requisito do usuário cliente:
- O cliente solicita a inserção de novos campos;
- O analista registra esses requisitos do cliente;
- O projetista (ou responsável) documenta as necessidades e passa para os envolvidos no desenvolvimento do sistema;
- O DBA cria na tabela X, os campos necessários conforme os requisitos;
- O programador altera os Beans, DAOS, Façades, etc., para setar e capturar os valores dos atributos;
- O programador dá check in dos arquivos alterados no servidor de controle de versão;
- Os testers possivelmente efetuam testes do que foi sincronizado de novo no sistema;
- É preparado então, um pacote de entrega para que o usuário possa começar a utilizar o sistema com os novos requisitos implementados;
É explicito um certo trabalho que dá para a área de desenvolvimento. É lógico, muitas empresas pensam em elaborar um contrato onde indica que cada requisição do gênero, terá um valor a ser cobrado e blá blá blá, etc. etc. etc. Porém, vamos pensar diferente. Vamos pensar em dinamismo. E como isso é possível? Criando Beans dinâmicos!
Não seria o ideal (mesmo que seja um pouco complicado) implementar um código genérico onde um objeto (já instanciado, é claro) represente de forma automática o modelo de dados de nossa aplicação? Isso não seria o ideal, tanto para nós quanto (e principalmente) para nossos clientes? Além de oferecer, esse mecanismo possibilida uma flexibilidade tornando uma feature a mais em nosso sistema empresarial, sem termos que nos preocupar com o início de um fluxo em nosso processo de trabalho para a implementação do mesmo, eliminando tempo e custo para o desenvolvimento.
O que eu estou abordando neste artigo, não é nada novo, porém, muitos programadores já passaram por essa situação (muitas e muitas vezes) até que um indivíduo resolveu elaborar um padrão de projeto (design pattern) para que pessoas, assim como eu e você, não fiquem quebrando a cabeça pensando em “como implementar” algo do genero. Esse design pattern é conhecido como Dynamic Object Models. O responsável por essa “obra de arte” é um cara chamado Ralph Johnson, que hoje pertence ao GoF (Gang of Four). O DOM (Dynamic Object Models) possui uma estrutura que consitui de outros patterns existentes e reconhecidos na engenharia de software. Por isso é altamente aconselhável o estudo (ou pelo menos um breve conhecimento) sobre os Design Patterns.
A estrutura do DOM é composta pelos seguintes patterns:
- Type Object (Entity / EntityType; Attributes / AttributesTypes);
- Property (Property type);
- Strategy;
O pattern mais importante no DOM é o Type Object na qual separa uma Entity em um Entity Type. Vamos tratar nosso beans sendo entitys, e como sabemos, nossas entitys possuem atributos, na qual serão implementados com o pattern Property. Para separarmos os atributos para os nosso tipos de atributos, iremos utilizar o pattern Type Object. O pattern Strategy é utilizado para definir o comportamento de um tipo de entidade (no caso, EntityType) [1].
A Figura 1 nos apresenta o relacionamento entre cada artefato do DOM:
Resumindo a idéia geral do DOM, os modelos dinâmicos são baseados em tipos de classes que conterão as informações dos atributos e esses atributos definidos por meta-dados (na qual veremos a seguir).
Partindo para a fase de implementação, vamos desenvolver algo no seguinte cenário:
- Um cliente precisa criar novos atributos para um bean (Entidade) dinâmico(a);
- Este bean representará um simples cadastro de pessoa;
- Precisamos gerar e setar os atributos do bean dinâmicamente;
- Nossos beans terão como fonte de referência, um arquivo .properties que servirá como um meta-dado e informará quais serão os atributos e seus tipos de dados;
Construindo nossas classes
Para colocarmos em prática o nosso estudo, vamos criar uma estrutura com algumas classes e um arquivo.properties que representará a nossa fonte de informação para a criação do bean. O nosso .properties deverá se chamar dynabean.properties e conterá as seguintes informações (Lista 1):
No nosso caso, teremos uma entidade que será composta por três atributos (nome, dataNascimento e filhos). Cada atributo deverá ser um “tipo de atributo”. No nosso caso, vamos implementar o nosso “tipo de atributo” (ou PropertyType) na classe DynaBeanAttribute da seguinte forma:
Já o nosso Bean, será composto de DynaBeanAttribute`s, getter`s e setter`s.
Necessariamente utilizamos generics (HashMap <String, DynaBeanAttribute>) para obrigarmos com que os únicos argumentos sejam do tipo String – representa o nome do atributo – e DynaBeanAttribute.
Para a construção do nosso Bean, iremos utilizar um outro pattern (Factory) que será responsável pela “conexão” com o nosso dicionário de dados (no caso, um .properties) e retornará um Bean criado dinâmicamente contendo todos os atributos descritos no .properties.
A idéia do DOM pode ser aplicado de diversas maneiras, porém, iremos implementar a Factory (Lista 4) como idéia de uma facilitadora para a nossa aplicação.
Para testarmos, vamos criar uma classe (conforme a Lista 5) contendo a assinatura main e a construção de nosso Bean a partir da nossa Factory:
O que criamos exatamente foi uma classe que representará uma entidade (em algum lugar no banco, ou em qualquer outro lugar) que contém atributos pertinentes a aquela classe. Visualizando esse cenário, nós poderíamos expandir nossas idéias, como por exemplo, utilizar um dicionário de meta-dados SGDB ou XML para a elaboração dos beans dinâmicos, ao invés de utilizar um simples arquivo .properties. A utilização do .properties é somente uma idéia ilustrativa de meta-dados para os nossos beans. Nossos beans precisam ter a concepção do que eles serão constituídos, e essas informações estarão disponíveis em algum tipo de dicionário de dados em forma de meta-dados. Partindo deste princípio, poderíamos elaborar um simples esquema que persistisse esses dados de forma genérica utilizando a API de persistência de objetos do pattern EJB3, ou até mesmo utilizando Hibernate com Annotations.
Estas idéias serão implementadas em uma próxima oportunidade. Só gostaria de ressaltar que o exemplo apresentado, foi algo visto em sala de aula no curso de Pós-graduação, e como achei interessante sua aplicabilidade, resolvi apresentar o mesmo para vocês.
Conclusão
Através do DOM, é possível enxergar uma série de soluções que aplicam a formação e a construção de objetos, beans ou modelos dinâmicos. A flexibilidade se torna uma característica extensível em várias áreas de nossa aplicação. Empresas que desenvolvem aplicações voltadas para a Gestão Empresarial Integrada (ERP, EAI, etc) e aplicam destes conceitos em seus sistemas, oferecem um diferencial de produto para seus clientes e para o mercado. Elaborar aplicações baseadas em uma arquitetura DOM podem significativamente reduzir uma série de questões problemáticas, que envolvem desde princípios de cada empresa e principalmente de cada cliente. Pense bem nesta idéia.
