Anotações Próximas ao Domínio da Sua Aplicação

Transcrição

1 Atualmente, a comunidade de desenvolvimento de software entende que, ao se desenvolver software, a verdadeira complexidade está, na maioria das vezes, no domínio onde a aplicação se encaixa. A intenção do Domainc a p a Eduardo Guerra é pesquisador em desenvolvimento de frameworks, participando de projetos open-source como SwingBean, Esfinge Framework, ClassMock e JColtrane. Atualmente está cursando doutorado no ITA, onde também já concluiu graduação em Engenharia da Computação e mestrado. Possui as certificações SCJA, SCJP, SCWCD, SCBCD (1.3 e 5.0), SCJWSD, SCMAD e SCEA e experiência como arquiteto de software nas plataformas Java SE, Java EE e Java ME. Atua também como professor na graduação do ITA e nos cursos de pósgraduação ITA/Stefanini. Roberto Perillo (jrcperillo@yahoo.com.br) é bacharel em Ciência da Computação e está atualmente cursando mestrado no ITA, onde já concluiu o curso de especialização em Engenharia de Software. Trabalha com Java há quase 5 anos, possui as certificações SCJP, SCWCD e SCJD, e é moderador no JavaRanch, onde participa ativamente dos fóruns. Já trabalhou com JEE em grandes empresas, como Avaya e IBM, onde, nesta última, foi co-fundador do time de inovação de ibm. com GWPS LA. DomainAnnotations: Anotações Próximas ao Domínio da Sua Aplicação Aprenda a aplicar os conceitos do Domain-Driven Design nas anotações da sua aplicação. O Domain-Driven Design prega que não devemos misturar código de infraestrutura com regras de domínio. Porém, quando utilizamos anotações para configurar segurança ou gerenciamento de transações em um EJB, é exatamente isso que acontece! Anotações relacionadas com a infraestrutura e requisitos não-funcionais estão cada vez mais invadindo as classes que implementam as regras de negócio. O objetivo deste artigo é apresentar as anotações de domínio, um conceito que ajuda a modularizar melhor as anotações em uma aplicação. DQ uando as anotações surgiram na linguagem Java, muita gente disse que não gostava da ideia, pois elas poderiam gerar uma grande poluição no código das classes. Na verdade, qualquer recurso de linguagem mal empregado pode gerar perda de legibilidade no código-fonte. É preciso aplicar boas práticas de programação para a criação de um bom código e as anotações não fogem a essa regra! O grande problema é que quando as anotações surgiram, ninguém ainda havia as utilizado o suficiente para saber o que era uma boa prática. Felizmente, as coisas estão mudando! 23

2 Driven Design é acelerar o desenvolvimento de softwares que lidam com domínios complexos através de um conjunto de práticas, essencialmente conectando implementação a um modelo que evolui constantemente. A principal atividade do Domain-Driven Design é a modelagem de domínio, que busca criar uma abstração rigorosa e selecionada do conhecimento que os especialistas do domínio possuem. No cenário dos frameworks, o conceito de metadados tem sido cada vez mais explorado, e tem representado uma melhora na modularidade do desenvolvimento dos próprios frameworks. Os metadados nada mais são que dados sobre dados. Em outras palavras, consiste em um número predefinido de elementos que representam atributos específicos de um determinado recurso. As anotações surgiram na versão 5 da linguagem Java, caracterizando assim uma nova forma de definição de metadados. A ideia fora inspirada inicialmente pela ferramenta XDoclet, onde tags especiais JavaDoc são naturalmente colocados em comentários JavaDoc que anotam elementos de classes. Diante dessas tags, a ferramenta gera desde arquivos XML até classes compiladas. Em termos de código, a manifestação do modelo de domínio se dá na camada de domínio, que deve idealmente ficar isolada das outras camadas. No entanto, existem algumas situações onde a camada de domínio acaba sofrendo efeitos externos para que um determinado objetivo seja alcançado. Por exemplo, após a introdução das anotações na linguagem Java, os frameworks passaram a fornecê-las como forma de obter metadados em tempo de execução, e diante dessas anotações, executar uma determinada rotina. Ao utilizar anotações específicas de um framework, os seguintes problemas podem ocorrer: diminuindo sua manutenibilidade e legibilidade; das em elementos relacionados com o domínio; Uma solução para esses problemas são as anotações de domínio, que buscam representar metadados nas classes de domínio através de conceitos do próprio domínio. Dessa forma, a camada de domínio permanece isolada das outras camadas, proporcionando assim mais modularidade e reúso. Este artigo faz uma pequena introdução às anotações para a linguagem Java, mostrando os principais problemas que podem ocorrer na sua utilização. Em seguida são apresentadas as Domain Annotations, exemplificadas com alguns frameworks recentes que já suportam o mapeamento de anotações, onde esse conceito pode ser aplicado. Por fim, é apresentada a ferramenta Daileon (Domain Annotations Identifier and LEgacy annotations arranger), que permite que frameworks suportem a abordagem de anotações de domínio através de mapeamento dinâmico de anotações, e permite também que essa abordagem seja utilizada com frameworks já existentes que não suportam a abordagem de nenhuma forma, através mapeamento estático de anotações. Anotações na Linguagem Java A história das anotações em código na linguagem Java, vem desde antes do lançamento do Java 5. Tudo começou quando os frameworks e APIs precisavam de alguma forma obter informações adicionais a respeito das classes do sistema. Essas informações são chamadas de metadados e podem ser utilizadas para configurar dados para os mais diversos propósitos como: quais as restrições de segurança de um método, para qual coluna um atributo deve ser mapeado em um banco de dados e qual tipo de requisição web deve ser tratada por uma classe. Sem haver uma forma de definir essas informações no código, os frameworks utilizavam formas de definição externa, normalmente documentos XML. Esses documentos XML acabavam ficando grandes e difíceis de serem gerenciados em projetos grandes. Dessa forma, os desenvolvedores buscaram formas alternativas de se trabalhar com esses descritores, que normalmente envolviam a utilização de uma ferramenta. O XDoclet é uma engine de geração de código que foi muito popular na época do EJB 2.1 e do Hibernate 2. Ela utilizava tags do JavaDoc para definir informações adicionais sobre membros de classes que poderiam ser utilizadas na geração dos descritores XML ou mesmo de código-fonte. A Listagem 1 apresenta um exemplo de definição de metadados utilizando o XDoclet para a criação de um EJB da versão 2.1. Listagem 1. Exemplo do uso do XDoclet retirado do site do projeto. /** * This is an account bean. It is an example of how to use the * EJBDoclet tags. * Customer Accounts are owned by customers, and a customer can * have many accounts. * name= bank/account * type= CMP * jndi-name= ejb/bank/account * primkey-field= id signature= Collection findall() * unchecked= true remote-class= test.interfaces.account */ O XDocLet foi a primeira abordagem que permitiu que na linguagem Java fossem definidos metadados diretamente no código. Essa abordagem foi chamada de Attribute-Oriented Programming, devido ao fato dela trabalhar com a definição de atributos adicionais para os elementos do código. Essa abordagem despertou a atenção da comunidade e no Java 5, a partir da JSR 175, as anotações entraram de forma nativa na linguagem Java. A grande promessa que se escutava era que seria o fim dos grandes descritores XML para aplicações corporativas (Java EE). Por mais que algumas pessoas criticassem esse novo recurso por dizer que ele poderia poluir o código, a verdade é que a chegada das anotações mudou a cara de grande parte dos frameworks e APIs utilizados pelos desenvolvedores. O Java EE 5 foi um dos pioneiros ao apresentar um modelo de como a utilização de anotações pode simplificar bastante a criação de aplicações, consequentemente aumentando a produtividade da equipe. A desburocratização no desenvolvimento de EJBs com a versão 3, mostrou como esse recurso pode tornar mais simples o modelo de programação utilizado. Com isso, em pouco tempo, diversos outros frameworks começaram a seguir o mesmo caminho. Hoje em dia, é difícil encontrar um framework ou API mais recente que não faça uso de anotações. Além de ser uma alternativa a criação de grandes documentos XML, as anotações também podem trazer outros benefícios. Os frameworks anteriormente definiam interfaces que deveriam ser implementadas ou superclasses que deveriam ser estendidas pelas classes da aplicação 24

3 que seriam utilizadas por ele. Isso de certa forma amarrava a estrutura da classe a um formato estabelecido pelo framework. Com o uso de anotações, diversos frameworks identificam os métodos que devem ser chamados através das anotações, eliminando a necessidade da classe implementar os protocolos predeterminados pelo framework. Isso reduz o acoplamento da classe com o framework, trazendo benefícios como maior flexibilidade e testabilidade. Para aqueles que ainda não estão familiarizados com a forma que as anotações funcionam na linguagem Java, o quadro Conheça as Anotações dá uma pequena introdução sobre o assunto. Problemas com anotações Nem tudo são flores quando se utiliza anotações e, se os desenvolvedores não tomarem cuidado, elas podem trazer alguns problemas. O problema se agrava ainda mais no momento em que diversos frameworks com essa característica, começam a aumentar e a se misturar. Essa seção descreve algumas questões relacionadas à manutenibilidade que devem ser consideradas ao utilizarmos frameworks baseados em metadados nas aplicações. A primeira questão que devemos considerar é o excesso de anotações, que gera uma poluição no código que impacta negativamente em sua legibilidade. Quem não é muito chegado em anotações, essa costuma ser sua principal justificativa. Este excesso tem uma chance maior de acontecer quando mais de um framework é utilizado na mesma aplicação. O problema pode acontecer de diversas formas, como, por exemplo, com diversas anotações no mesmo elemento ou anotações dispersas por toda classe. Muitas vezes o número de anotações não é o problema e sim a quantidade de atributos. Em alguns casos, existem classes que possuem mais anotações do que código imperativo. Esse tipo de situação faz com que a legibilidade da classe diminua, causando dificuldades para evolução e manutenção. Outro problema que pode ocorrer é a duplicação de configurações via anotação. Imagine, por exemplo, que se configure uma classe através de uma anotação, como ocorre com a do EJB 3. Caso uma classe tenha sido configurada em diversos métodos e depois ela precise ser trocada por outra, será necessário um grande esforço para localizar os pontos para essa substituição e efetivamente realizá-la. A duplicação de anotações, como qualquer tipo de duplicação de código, não é uma boa prática e pode trazer grandes dificuldades para fazer al- Conheça as anotações Para quem ainda não conhece mais profundamente as anotações, uma confusão comum é achar que elas adicionam comportamento nas classes anotadas. Na verdade, elas não fazem absolutamente nada, a não ser adicionar uma informação no elemento anotado. Para que sua presença surta algum efeito, é preciso que um framework ou uma ferramenta leia aquela informação e faça alguma coisa a partir dela. As anotações são declaradas com a Apesar de não permitirem a definição de comportamento, elas podem possuir atributos cujos valores são configurados no momento do uso da anotação. Esses atributos podem ser tipos primitivos, enumerações, anotações, Strings, classes ou um array de qualquer um desses. Nas definições de anotações também é comum o uso de anotações (isso mesmo, são anotações que anotam anotações) para a definição de características e informações complementares para o seu processamento. Segue o exemplo de uma anotação que define um intervalo válido de valores para um atributo Intervalo { int inicio(); int final(); Essa anotação utiliza a para definir que ela deve ser mantida na classe até em tempo de execução. Outras opções seriam SOURCE, em que ela é removida da classe após a compilação, e CLASS, em que ela é mantida na classe compilada, mas não é carregada para a máquina virtual. Outra anotação importante é que indica os tipos de elementos que podem ser anotados, no caso somente atributos pelo valor ser FIELD. Outras opções seriam: TYPE (classe, interface e enumeração), METHOD, CONSTRUCTOR, PARAMETER, LOCAL_VARIABLE, PACKAGE e ANNOTATION_TYPE. A seguir, um exemplo de uso da anotação definida: public class Filme{ private String final=18) private int censura;... É importante lembrar mais uma vez que uma anotação sozinha não adiciona comportamento. Para ler essa anotação em tempo de execução (para isso ser possível precisa ser RUNTIME), basta acessar a classe via API Reflection e selecionar os elementos de código onde deseja procurar as anotações. Classes da API Reflection que representam classes, métodos, atributos e até mesmo anotações, implementam uma interface chamada AnnotatedElemment. Essa interface possui métodos que possibilitam verificar se uma anotação está presente, isannotation- Present, recuperar uma anotação específica pelo seu tipo, getannotation, e recuperar todas as anotações, getannotations. Para os interessados em se aprofundar no assunto, recomendamos fortemente a leitura do artigo Reflexão + Anotações Uma Combinação Explosiva, da revista Mundoj, edição

4 terações. Alguns frameworks e APIs implementam estratégias para evitar a duplicação, como permitir configurações mais gerais em arquivos XML. Entretanto, esse tipo de prática não é uma regra para frameworks e em alguns casos a duplicação é inevitável. O acoplamento entre classes ocorre quando uma classe invoca métodos de outra, para a qual parte da funcionalidade é delegada. O uso de anotações em uma classe não a acopla diretamente ao framework, pois seu comportamento não é influenciado por elas. Porém, o funcionamento da aplicação onde àquela classe está inserida é sim influenciada pela presença das anotações. Dessa forma, dizemos que essa dependência causa um tipo diferente de acoplamento, chamado de indireto ou semântico. É esse acoplamento que dificulta, por exemplo, se quisermos mudar de framework, visto que cada um trabalha com um esquema de anotações diferente. Como consequência, podemos dizer que o comportamento da aplicação é dependente daquele framework, visto que suas classes estão indiretamente acopladas com seu esquema de anotações. Assustado? Por favor, não desista ainda das anotações, pois nas próximas seções será apresentado o uso de anotações de domínio, que podem ajudar a evitar todos esses problemas! Domain Annotations A abordagem conhecida como Domain-Driven Design é uma compilação de práticas que ajudam a desenvolver aplicações para domínios complexos, essencialmente conectando implementação a um modelo que evolui constantemente. Uma das práticas promovidas é a chamada modelagem de domínio, que busca criar uma abstração de como as coisas acontecem no mundo real, contemplando somente os aspectos que devem ser refletidos no software. Dessa forma, o maior produto do Domain-Driven Design é o modelo de domínio. De acordo com Eric Evans, modelo pode ser definido como um sistema de abstrações que descreve aspectos selecionados de um domínio e pode ser usado para resolver problemas relacionados àquele domínio, e domínio pode ser definido como uma esfera de conhecimento, influência ou atividade. Assim, modelo de domínio pode ser definido como uma abstração do conhecimento dos domain experts rigorosamente organizada e selecionada. É importante ressaltar que o modelo de domínio é somente uma abstração, e não um diagrama UML, por exemplo. Embora seja comumente representado através de diagramas UML, pode na prática ser representado por qualquer coisa que seja capaz de refleti-lo, como textos ou figuras. Em termos de código, a manifestação deste modelo de domínio se dá na camada de domínio da aplicação, onde são concentradas todas as regras de negócio que devem ser implementadas pelo software. Modelo de domínio também é um padrão de organização de lógica de domínio, e quando utilizado, modifica de forma profunda a arquitetura da aplicação. A maioria das classes que compõe esse padrão possui tanto dados quanto comportamentos, e as regras de negócio são implementadas pelas entidades do domínio. Por exemplo, no domínio de eletroeletrônicos, poderia existir uma interface chamada Eletronico com um método ligar, uma classe abstrata chamada AparelhoEletronico que implementa a interface Eletronico, e uma classe chamada Televisor que estende AparelhoEletronico e possui um método mudarcanal. Dessa forma, a lógica é implementada no código que reflete o modelo de domínio, e não mais em classes de negócio que utilizam entidades burras para se comunicar com as camadas de persistência e apresentação. A implementação do modelo de domínio deve idealmente ficar livre de qualquer código que não seja relacionado ao próprio domínio. No entanto, existem algumas situações em que esse código acaba tendo que receber algum código não relacionado ao domínio para que um determinado objetivo seja alcançado, como, por exemplo, em uma situação onde é necessário adicionar anotações ao código de domínio para tirar proveito de uma determinada funcionalidade de um framework relacionado à segurança. Dessa forma, o código de domínio acaba sendo invadido por anotações externas que não dizem respeito ao domínio, ficando assim semanticamente acoplado aos frameworks que fornecem essas anotações. O conceito de anotações de domínio propõe representar metadados na camada de domínio através de conceitos do próprio domínio e, dessa forma, a camada de domínio passa a não mais receber anotações externas ao próprio domínio, o que a mantém pura. O principal motivo para se isolar a camada de domínio é a evolução do software, pois, dessa forma, torna-se mais fácil manter e evoluir o software com o passar do tempo. Os principais benefícios dessa abordagem são: direta com o próprio domínio, o que ajuda a manter a camada de domínio isolada; ção seja construída fica encapsulada; Apesar destes benefícios, os principais objetivos deste tipo de anotação é promover mais modularidade e mais reusabilidade. Ao definir anotações de domínio, é possível mapeá-las para outras anotações, o que permite que os frameworks utilizados pela aplicação sejam trocados sem que o código relacionado ao domínio precise ser modificado. Além disso, como Rodrigo Yoshima sabiamente mencionou no artigo Patterns no Desenvolvimento de Software Moderno, na edição de número 39 da revista Mundoj, elementos de negócio são amplamente reutilizados nas organizações, e as anotações de domínio também permitem que os elementos de domínio sejam reutilizados com outros frameworks em contextos diferentes do que a aplicação fora inicialmente projetada. Naturalmente, este tipo de anotação requer um tratamento especial, para que seja possível reconhecê-la no código e identificar a quais anotações uma determinada anotação de domínio corresponde. Este tratamento pode ser feito pelo próprio framework de forma dinâmica, porém ainda poucos dão suporte a essa abordagem. Uma alternativa nos casos em que o framework não suporta essa abordagem é fazer o mapeamento estático das anotações com uma ferramenta como o Daileon, que será apresentada nas próximas seções. Domain Annotations em frameworks existentes Na verdade, nenhum framework dá suporte a anotações de domínio diretamente, eles dão suporte, na verdade, ao mapeamento de anotações, o qual pode ser usado na criação de anotações de domínio. Fazendo um paralelo, a orientação a objetos proporciona recursos como herança e polimorfismo, porém a aplicação pode utilizar este recurso de diversas formas diferentes. Analogamente, o mapeamento de anotações permite que sejam criadas novas anotações que representam as anotações do framework. Esse conceito pode ser utilizado para a criação de anotações de domínio, porém nada impede que seja criada uma anotação que não 26

5 seja relacionada com o domínio da aplicação. O uso de Domain Annotations é uma escolha de modelagem de quem utiliza esse recurso de mapeamento. Os primeiros frameworks e APIs que utilizaram anotações não suportavam esse tipo de mapeamento. À medida que a comunidade Java foi ganhando experiência nesse novo recurso de linguagem, começou-se a perceber que permitir o usuário do framework a definir suas próprias anotações a partir das já existentes, é uma ferramenta poderosa que pode eliminar vários dos problemas no uso de anotações citados anteriormente nesse artigo. Porém, os frameworks que já suportam esse tipo de mapeamento são bem recentes e começaram a aparecer por volta de meados do ano de Um exemplo é a JSR 303 Bean Validation, que teve seu Final Release datado no dia 16 de novembro de Pela especificação, é possível definir uma nova anotação, a qual é feita com as anotações de validação da API. Dessa forma, é possível criar anotações de domínio que encapsulam as anotações do framework. A Listagem 2 apresenta o exemplo da que define as regras de validação na qual um número deve ser diferente de nulo e estar entre 0 e 122 (que, por curiosidade, foi a idade em que faleceu Jeanne Calment, considerada a pessoa mais velha que já viveu no mundo). Anotar uma propriedade teria o mesmo efeito para a validação do que anotá-la com que escrevem a anotação. Mas o que se ganha criando essa anotação intermediária? O principal ganho é que além de serem configuradas as informações a respeito da validação, uma informação adicional é criada: que aquele campo está representando uma idade. Essa informação, que diz respeito ao domínio da aplicação, pode ser utilizada para outras coisas, como, por exemplo, para escrever anos depois do valor quando essa propriedade for impressa. Além disso, é possível perceber que essa prática irá diminuir o número de anotações na classe que utilizá-la, além de reduzir seu acoplamento semântico com as anotações do framework. Quando este tipo de anotação é utilizada em mais de um local, também é fácil perceber que ela ajuda a remover a duplicação de configurações. No exemplo da Listagem 2, se algo precisar ser alterado (por exemplo, se alguém no mundo fizer 123 anos) só é necessário alterar as configurações em um local. Listagem 2. Exemplo de uma anotação de validação criada pela composição de Idade { String message() default Idade Inválida ; Class<?> [] groups() default {; Class<? extends Payload> [] payload() default {; Outros exemplos de frameworks e APIs que já dão suporte a esse tipo de mapeamento são o Spring 3 e a especificação CDI do JavaEE 6. Inclusive essa segunda foi apresentada no artigo CDI Injeção de Dependência e Gerenciamento de Contextos no Java EE 6 da edição anterior da revista Mundoj. Neste artigo, a Seção Agrupando Características de um Bean apresenta como utilizar o que é chamado de Stereotype, que nada mais é do que uma anotação criada pela aplicação para agrupar uma série de configurações. Esse recurso pode ser utilizado para criar metadados em forma de anotações que façam sentido dentro do domínio da aplicação. Permitindo anotações de domínio As anotações de domínio não deixam de ser anotações customizadas, que são criadas no momento em que a aplicação é criada. Dessa forma, os frameworks utilizados pela aplicação não conhecem essas anotações. Uma das funcionalidades oferecidas pelo Daileon é a capacidade de permitir que frameworks reconheçam anotações de domínio, ou seja, anotações que não são conhecidas pelos frameworks utilizados na construção da aplicação (sim, os autores deste artigo e da ferramenta eram fãs de Jaspion na infância!). Para que uma anotação possa ser consumida, o framework que a disponibiliza precisa conhecê-la, para que seja possível recuperá-la na definição da classe em tempo de execução e então interpretá-la. Por exemplo, consideremos um exemplo no qual um framework X fornece a anotação indicada na Listagem 3. Diante dessa anotação, o framework X exibe no console a mensagem indicada na própria anotação. Listagem 3. Definição da anotação fornecida pelo framework MessageTrigger { public abstract String value(); No exemplo mostrado na Listagem 3, a pode anotar somente métodos como indica a Uma aplicação que utiliza o framework X pode anotar um método com a MessageTrigger, e então a mensagem indicada na anotação será exibida no console. Listagem 4. Um método de uma aplicação utilizando a MessageTrigger. public class Bicicleta I ve got a bike, you can ride it if you like! ) public void mudarmarcha(int marcha) { Para que a anotação possa ser consumida, o framework X precisa de uma referência à classe Bicicleta, mostrada na Listagem 4. Em um cenário real, o framework pode, por exemplo, requerer que um arquivo XML seja construído, indicando as classes anotadas com suas anotações, e assim as classes podem ser instanciadas via reflexão e suas estruturas podem assim ser lidas. O exemplo mostrado na Listagem 5 apresenta como uma anotação pode ser consumida. Para simplificar a explicação, o método hipotético chamado showmessage é definido, e este possui uma referência estática à classe Bicicleta. O método mudarmarcha, da classe Bicicleta, também é recuperado de forma estática. 27

6 Listagem 5. Uma rotina no framework X consumindo a MessageTrigger. public void showmessage() throws Exception { Class<?> classreference = Bicicleta.class; Method mudarmarcha = classreference.getmethod( mudarmarcha, int.class); MessageTrigger annotation = mudarmarcha.getannotation(messagetrigger.class); String value = O valor da anotação é + annotation.value(); System.out.println(value); É possível agora substituir a pela anotação de domínio. A Listagem 8 mostra a classe Bicicleta utilizando a anotação de domínio. Listagem 8. Um método de uma aplicação utilizando a MessageTrigger. public class Bicicleta public void mudarmarcha(int marcha) { No exemplo apresentado na Listagem 5, o framework X possui um método showmessage, que quando acionado, recupera a MessageTrigger do método mudarmarcha da classe Bicicleta e o valor indicado na anotação é exibido no console. Nesse caso, o valor impresso é O valor da anotação é I ve got a bike, you can ride it if you like!. No método showmessage, o framework X consegue recuperar a MessageTrigger do método mudarmarcha da classe Bicicleta porque ele conhece essa anotação. No caso das anotações de domínio, o framework nunca as conhece, pois são criadas somente no momento em que a aplicação é construída. Para esses casos, o Daileon fornece uma biblioteca de funções que podem ser utilizadas para lidar com anotações que não são conhecidas pelo framework. Por exemplo, consideremos que agora o framework X vai permitir que aplicações utilizem também anotações de domínio. Nesse caso, o framework X deve permitir que suas anotações anotem outras anotações e também deve ser capaz de verificar a quais anotações uma anotação de domínio corresponde. Para esse segundo requisito, o Daileon fornece a classe DomainAnnotationsHelper, que possui alguns métodos estáticos que podem ser utilizados para esse propósito. A primeira coisa a fazer para que o framework X permita a utilização de anotações de domínio é alterar o código da para que ela possa anotar também outras anotações. Listagem 6. Redefinição ElementType.ANNOTATION_TYPE) MessageTrigger { public abstract String value(); Agora que a pode anotar outras anotações, pode-se então definir a anotação de domínio. Listagem 7. Definição da anotação @MessageTrigger( I ve got a bike, you can ride it if you like! ) AlteradorVelocidade { Agora, ao invés de procurar por suas próprias anotações, como mostrado na Listagem 5, o framework solicita ao método getannotation da classe DomainAnnotationsHelper do Daileon a passando o método mudarmarcha e a como parâmetros. Pode-se também verificar se a está presente no método antes de tentar recuperá-la, utilizando o método isannotationpresent, também da classe DomainAnnotationsHelper do Daileon. Listagem 9. Uma rotina no framework X consumindo a através da anotação de domínio. public void showmessage() throws Exception { Class<?> classreference = Bicicleta.class; Method mudarmarcha = classreference.getmethod( mudarmarcha, int.class); // Verificando se a anota indiretamente // o método mudarmarcha if (DomainAnnotationsHelper.isAnnotationPresent(mudarMarcha, MessageTrigger.class) { // Recuperando a do método // mudarmarcha MessageTrigger annotation = DomainAnnotationsHelper.getAnnotation(mudarMarcha, MessageTrigger.class); String value = O valor da anotação é + annotation.value(); System.out.println(value); No exemplo mostrado na Listagem 9, é possível recuperar a MessageTrigger do método mudarmarcha mesmo que essa anotação não o escreva diretamente porque a escreve a que é a anotação de domínio definida nesse exemplo que anota diretamente o método mudarmarcha. Essa anotação de domínio também é escrita com a fornecida pelo Daileon, para que ele possa identificar que uma dada anotação é de domínio. Diante do método e da anotação procurada, o método getannotation do Daileon recupera a anotação procurada pelo framework. Uma das vantagens dessa abordagem é que assim é possível acrescentar outras anotações, se necessário, sem alterar o código das classes de domínio. Por exemplo, é possível adicionar outras anotações à sem a necessidade de alterar a classe Bicicleta. Além disso, também é possível anotar uma anotação de domínio com 28

7 outra anotação de domínio, criando assim uma hierarquia de anotações. Nesse caso, a anotação de domínio que é escrita com outras anotações de domínio representa todas as anotações apresentadas por essas de domínio. A técnica mostrada nessa Seção refere-se a um mapeamento dinâmico, onde um determinado framework busca suas anotações em tempo de execução. Além disso, no exemplo apresentado, o framework X permite a utilização de anotações de domínio através do Daileon. Como seria a utilização de anotações de domínio com frameworks que já existem e que não suportam tal abordagem? Nesse caso, pode-se utilizar a ferramenta de tradução do Daileon, que traduz em nível de bytecode as anotações de domínio através da técnica de mapeamento estático. Mapeamento estático com o Daileon O Daileon permite que aplicações Java utilizem o conceito de anotações de domínio através de técnicas de mapeamento estático e dinâmico. Através do mapeamento dinâmico, a ferramenta permite que frameworks sejam feitos possibilitando a criação de anotações de domínio, e através do mapeamento estático, a ferramenta permite que as anotações de domínio sejam utilizadas mesmo com frameworks já existentes, que não as suportam de nenhuma forma. A segunda forma de criar anotações de domínio é quando elas substituem as anotações de frameworks que não suportam de nenhuma forma as anotações de domínio. Nesse caso, esses frameworks não esperam encontrar no código outras anotações que não sejam as suas. Por isso, antes da execução da aplicação, as anotações de domínio precisam ser substituídas por suas anotações correspondentes. Através da técnica de mapeamento estático, o Daileon verifica a quais anotações uma anotação de domínio corresponde e as traduz em nível de bytecode, para que a aplicação possa ser executada corretamente. Esse passo precisa, obviamente, ser executado antes que a aplicação seja feita, como uma espécie de segunda compilação. Revisitando o exemplo mostrado anteriormente, consideremos agora que o método mudarmarcha poderá ser acessado somente por usuários que estiverem no papel Administrador e também precisará de transacionalidade e, para tanto, o EJB 3 será utilizado. Para isso, a anotação de domínio precisa ser redefinida como mostra a Listagem 10. Listagem 10. Redefinição da anotação @MethodTemplate(annotatedClass = FrameworkAnnotationsHome, method = controlmethod ) AlteradorVelocidade { A anotação de domínio não mais é anotada com as anotações da API utilizada (nesse caso, o EJB 3). Na técnica de mapeamento estático, as anotações do framework utilizado ficam em classes criadas somente para guardá-las. A é mantida, e agora a anotação de domínio recebe uma anotação que indica uma classe e um método. É exatamente no método dessa classe que as anotações do EJB 3 estão localizadas. Isso é necessário porque, em alguns casos, frameworks permitem que suas anotações anotem somente elementos específicos, como métodos ou atributos, e não anotações. Por isso, além da o Daileon fornece outras duas, que que servem para indicar respectivamente que as anotações representadas pela anotação de domínio estão em nível de classe ou em um atributo. A classe que armazena as anotações do framework utilizado existe somente para esse propósito e, dessa forma, uma camada de metadados é adicionada entre o código do modelo de domínio e as anotações externas ao domínio. No exemplo mostrado na Listagem 10, as anotações do EJB 3 estão em um método chamado controlmethod, na classe FrameworkAnnotationsHome, como indica a O valor do atributo annotatedclass deve ser o nome totalmente qualificado da classe que armazena as anotações representadas pela anotação de domínio. A Listagem 11 mostra a estrutura da classe FrameworkAnnotationsHome. Listagem 11. Definição da classe que armazena as anotações do EJB 3. public class FrameworkAnnotationsHome Administrador public void controlmethod() { // Esse método existe somente para guardar as anotações // do EJB 3, portanto, não precisa ser implementado Nesse ponto, a anotação de domínio está definida e a classe que armazena suas anotações correspondentes já está criada. Agora, a anotação de representa duas anotações do EJB 3, mas poderia representar quantas fossem necessárias. Além disso, na técnica de mapeamento estático, também é possível anotar uma anotação de domínio com outra de domínio. No entanto, nesse caso, é importante que uma determinada anotação apareça somente uma vez em uma das anotações de domínio. Isso porque, até a versão 6 do Java, uma anotação pode escrever somente uma vez um determinado elemento. Embora seja possível manipular uma classe em nível de bytecode para que uma anotação apareça mais de uma vez em um elemento, no momento em que o Daileon encontra tal situação, é lançada a exceção DuplicateAnnotationException. O código da classe Bicicleta, mostrado na Listagem 10 ainda é o mesmo, o que mostra que há um ganho de modularidade ao utilizar a abordagem de anotações de domínio. Além de diminuir a complexidade das anotações (pois a anotação de domínio é única e representa quantas anotações forem necessárias), permite que os frameworks utilizados sejam trocados sem que o código seja alterado. Obviamente, as anotações de domínio precisam ser traduzidas em nível de bytecode para que a aplicação seja executada corretamente. Para efetuar a tradução, é necessário preparar um arquivo XML, indicando algumas configurações, antes de executar a ferramenta de tradução do Daileon. A Listagem 12 mostra um exemplo do arquivo de configuração XML necessário. 29

8 Listagem 12. Arquivo de configuração para a tradução das anotações de domínio. <?xml version= 1.0 encoding= UTF-8?> <daileon-config xmlns:xsi= xsi:nonamespaceschemalocation= daileon-config.xsd > <setup> <root-directory>c:\mj41\classes</root-directory> <destiny-directory>c:\mj41\modified classes</destiny-directory> <strategy-class> net.sf.daileon.notsupported.annotationsstrategy </strategy-class> <domain-annotations-replacer> net.sf.daileon.notsupported.domainannotationskeeper </domain-annotations-replacer> </setup> <domain-annotations> <annotated-class>bicicleta</annotated-class> </domain-annotations> </daileon-config> No arquivo de configuração, é necessário indicar alguns parâmetros de configuração e as classes anotadas com anotações de domínio, para que as transformações sejam efetuadas corretamente. No elemento <setup> são indicadas as configurações a serem utilizadas pela ferramenta. O elemento <root-directory> indica o caminho físico do primeiro pacote onde as classes a serem transformadas estão. Por exemplo, se o caminho físico de uma classe é C:\App\src\com\domain\MinhaClasse.class, então, o conteúdo desse elemento seria C:\App\src\com\. O elemento <destinydirectory> indica para onde as classes serão copiadas. Na verdade, as transformações não são efetuadas nas classes indicadas; ao invés disso, todas as classes são copiadas para o diretório indicado em <destinydirectory>, e a tradução é feita nessas cópias. Isso mantém as anotações de domínio nas classes originais, possibilitando assim traduzi-las para outras anotações caso seja necessário. O elemento <strategy-class> indica a classe que será responsável por organizar os elementos das classes e suas respectivas anotações. A ferramenta fornece a interface net.sf.daileon.notsupported.strategy e a implementação padrão net.sf.daileon.notsupported.annotationsstrategy, que naturalmente procura pelas anotações correspondentes às anotações de domínio nos elementos indicados MethodTemplate No entanto, o usuário da ferramenta pode implementar a interface Strategy e procurar pelas anotações correspondentes às anotações de domínio em outros lugares, como, por exemplo, arquivos XML, arquivos.properties, tabelas de banco de dados etc. Como o Daileon utiliza o framework ASM para efetuar a manipulação de bytecodes, então, se o usuário decidir implementar a interface Strategy, também terá que utilizar a versão do framework ASM para criar as anotações. Se o elemento <strategy-class> não for indicado no arquivo XML de configuração, o Daileon utiliza a implementação padrão AnnotationsStrategy. É possível indicar também se as anotações de domínio serão mantidas ou não no bytecode final após a tradução. A ferramenta possui duas implementações, net.sf.daileon.notsupported.domainannotationskeeper e net.sf.daileon.notsupported.domainannotationsdiscarder, que respectivamente as mantém ou as descarta no bytecode final. No entanto, o usuário pode criar uma implementação própria, indicando em quais casos uma anotação de domínio deve ou não ser mantida. Isso pode ser útil no caso em que uma anotação de domínio é utilizada por um framework que a reconhece, mas também deve ser traduzida para outras anotações de frameworks que não suportam essa abordagem. Para tanto, o usuário deve criar uma classe que implementa a classe abstrata net.sf.daileon. notsupported.abstractannotationsreplacer e implementar o método keepdomainannotations e indicar o nome totalmente qualificado dessa classe no elemento <domain-annotations-replacer> no arquivo XML de configuração. Se esse não for indicado no arquivo XML de configuração, o Daileon mantém todas as anotações de domínio no bytecode após a transformação. Finalmente, deve-se indicar dentro do nó <domain-annotations> todas as classes anotadas com anotações de domínio em elementos <annotatedclass>. Após preparar o arquivo de configuração, deve-se executar a ferramenta de tradução do Daileon a partir da linha de comando, da seguinte forma: java jar daileon.jar <caminho-do-arquivo-xml> Após a execução da ferramenta, todas as classes são copiadas para o local indicado no arquivo XML de configuração e as anotações de domínio são então traduzidas. Após a tradução, pode-se empacotar a aplicação conforme a necessidade e executá-la normalmente. Considerações finais Este artigo apresenta o conceito de anotações de domínio, que busca ajudar a camada de domínio a se manter isolada das outras camadas, proporcionando assim mais modularidade e reúso. Para habilitar o uso dessas anotações em aplicações Java, pode-se utilizar a ferramenta Daileon, que permite que novos frameworks sejam criados permitindo a criação e utilização de anotações de domínio por seus usuários, e também permite que elas sejam utilizadas com frameworks já existentes que não suportam tal abordagem. Em aplicações que utilizam Domain-Driven Design, as anotações de domínio permitem que a camada de domínio fique mais isolada das outras camadas. O principal motivo para se isolar a camada de domínio das outras camadas é a evolução do software. Dessa forma, torna-se mais fácil manter e evoluir o software com o passar do tempo. Além de ter relação direta com o domínio onde a aplicação se encaixa, as anotações de domínio permitem encapsular a dependência de frameworks que precisa existir para que a aplicação seja construída e deixam o código mais limpo, facilitando assim sua leitura e manutenção. Além disso, por serem capazes de representar quantas anotações for preciso, as anotações de domínio naturalmente diminuem a complexidade das anotações utilizadas na aplicação. Apesar desses benefícios, os maiores valores das anotações de domínio são modularidade e reusabilidade. Quando utilizadas, pode-se trocar os frameworks utilizados pela aplicação sem que o código que reflete o modelo de domínio seja alterado. Além disso, dessa forma, pode-se utilizar o código criado em contextos diferentes do que a aplicação fora inicialmente projetada, o que representa um ganho em reutilização de código. As técnicas aqui mostradas foram apresentadas no workshop RAM-SE do ECOOP (European Conference on Object-Oriented Programming) de 2009, que aconteceu em Genova, Itália, no dia 7 de julho. A ferramenta Daileon está atualmente na versão 1, e existem algumas novas funcionalidades que provavelmente venham a fazer parte da versão 2 da ferramenta. Até 30

9 lá, os desenvolvedores podem enviar sugestões aos autores deste artigo e utilizar a ferramenta para alcançar os benefícios aqui apresentados. A camada de domínio da sua aplicação agradece! Referências Referências 31