Criando Beans dinâmicos

Como vai senhores?

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:

Figura 1:

Boas Vindas a Daniel Costa

Olá galera da DevMedia. Referente ao convite do Eduardo Spínola, gostaria de me apresentar como novo colunista do Portal Java Magazine. Meu nome é Daniel Vieira Costa, tenho 22 anos, nascido em São Bernardo do Campo, porém, ao longo do tempo, acabei parando numa linda cidade chamada Foz do Iguaçu (Terra das Cataratas, ITAIPU Binacional e da muamba também), aqui no Paraná.

Atualmente estou trabalhando em uma empresa (DATAPAR) no Paraguai que atua no desenvolvimento de um software ERP para gestão de agrobusiness. Sou formado em Sistemas de Informação pela UDC (União Dinâmica Cataratas) e atualmente estou cursando na UTFPR (Universidade Tecnológica Federal do Paraná) o curso de Pós-graduação na área de “Desenvolvimento de Projetos Orientado a Objetos para a Internet”.

Desenvolvo sistemas a mais ou menos