Annotations poluem o codigo?

a vantagem de anotações sobre XML é qu anotações são verificadas em tempo de compilação, e não só em runtime

mas aquele é um exemplo extremo.

peguemos um exemplo do outro extremo:

Coloque quantos campos mais tu quiser, todos serão persistidos e tudo vai funcionar legaizinho

agora faz isto com XML pra gente ver

mudando um pouco de assunto, eu tava usando as anotacoes do h3 sempre nos getters, nao nos atributos. ha alguma diferenca?

Polui o codigo sim, mas classes de modelo normalmente sao beans bem simples e que nao fazem muita coisa.

Mas eh muuuuito legal voce escrever @E e dar um control espaco! Pronto, classe hibernetada.

urubatan wrote:a vantagem de anotações sobre XML é qu anotações são verificadas em tempo de compilação, e não só em runtime

No fundo, será que o problema não é das IDEs ?

Tanto annotations quanto os XMLs são usados para adicionar
metadados aos elementos da linguagem que serão usados em
determinado contexto.

Eu, particularmente, acho que as anotações, quando visualizadas da forma
atual, poluem o código. Acho que é aí o nó da questão.

Numa Dr. Dobbs +/- recente (acho que do ano passado), saiu um artigo de um cara advogando o uso do XML para o código fonte. Seu argumento: Qualquer equipe de desenvolvimento que quiser ter uma produtividade decente precisa de uma IDE. Todo mundo usa editores WYSIWYG, mas ninguem está precocupado como eles armazenam internamente (e no arquivo) a fonte utilizada em um parágrafo. Por que então deveríamos nos preocupar com isto no caso de código-fonte ? Quem determinou que, para toda existência, o fonte de um programa será texto-puro ? BTW, até o VB4 acho que ainda havia a opção de salvar o fonte em "formato binário".

Tanto o XML quanto as anotações são pouco legíveis, encaremos este fato...

Imagino que a evolução natural das IDEs irá levá-las a ocultar as anotações, pelo menos na visão padrão do editor do fonte. O programador, clicando com o botão direito do mouse sobre um atributo ou usando um atalho, teria acesso a um diálogo amigável para preencher os metadados. Preencheu, fechou, pronto: de volta para um fonte limpo - pelo menos na aparência.

Para suportar isto, uma representação XML do fonte cai bem. Usando namespaces seria fácil suportar novas extensões e, em princípio, o próprio processo de compilação poderia expandido para incluir passos de verificação adicionais. Pex, no caso do Hibernate, um plugin para o compilador poderia acessar a base de dados e verificar se as tabelas criadas existem, se são compatíveis, etc.

psevestre wrote:
Numa Dr. Dobbs +/- recente (acho que do ano passado), saiu um artigo de um cara advogando o uso do XML para o código fonte.

esse?

AllMighty wrote:

psevestre wrote:
Numa Dr. Dobbs +/- recente (acho que do ano passado), saiu um artigo de um cara advogando o uso do XML para o código fonte.

esse?

Possivelmente. Ao menos a linha de argumentação é a mesma. Mas o artigo que li não era este, nem o da ACM.

urubatan wrote:mas aquele é um exemplo extremo.

A ideia era exagerar para deixar claro. No fim das contas, apenas remover todas as queries para um package-info já ajuda um bocado. Fora elas, não acho que o exemplo seja tão absurdo assim, especialmente quando for preciso usar outra anotações.

Paulo Silveira wrote:mudando um pouco de assunto, eu tava usando as anotacoes do h3 sempre nos getters, nao nos atributos. ha alguma diferenca?

Prática acho que não. Eu comecei a usar nos fields porque nos primeiros releases havia alguns bugs bobos quando se usava nos getters.

valeuz...

Poxa gente. Esse codigo eh que nem jsp.

O pessoal abusa.

QUALQUER tecnologia eh soh cuidar e nao abusar que funciona sem problemas. Seja ela jsp, hibernate annotations ou ate mesmo visual basic.

ps: Ja nao falo o mesmo sobre o struts (preconceito

HelloWorld Membro desde: 20/02/2005 17:33:37 Mensagens: 11 Offline

Pessoal, desculpem reativar essa thread velha, mas achei que valeria a pena reaproveitar a discussão.

Seguinte, aqui na empresa vamos começar a utilizar o Hibernate (com um pequeno atraso, hehehe) e quando nos deparamos com a possibilidade de utilizar annotations o pessoal ficou meio reticente à idéia porque, na argumentação deles, não estaríamos promovendo o separation of concerns, já que estaríamos colocando coisas da camada de persistência nos POJOs do negócio. Confesso que, apesar de ser simpático ao uso de annotations, principalmente pelo fato de não ter mais um arquivo (XML) pra manter, achei que o argumento tinha algum fundamento.

O que vocês acham dessa argumentação? Se fosse pra dar uma palavra final, qual seria a de vocês?

Agradeço desde já a manifestação de vcs.

[]'s

dmitsuo wrote:

não estaríamos promovendo o separation of concerns, já que estaríamos colocando coisas da camada de persistência nos POJOs do negócio.
[]'s

Embora eu seja _antipático_ aos annotations, não acho que o argumento faça sentido. IMO, a questão do "separation of concerns" tem a ver com a forma de modelar suas classes, e não como se faz o mapeamento objeto-relacional das mesmas - até porque este mapeamento pode nem existir, dependendo da tecnologia.

O fato de vc. poder _optar_ entre colocar as definições de persistência tanto via annotation quanto por xml já deixa isto claro. Como "prova", importe para uma ferramenta UML qualquer o modelo com annotations e sem. O modelo UML será o mesmo, certo ?, Como a análise sobre se existe ou não "separation of concerns" deve ser feita neste nível e os dois modelos são idênticos na visão UML, não há diferença, neste aspecto, quanto ao uso ou não de annotations.

por acaso eu achei esse tópico no google...e estava pensando exatamente nisso...aí vejo o post datado de 2005...hoje após 3 anos as anotações tem tomado mais espaço e não só o hibernate precisam delas...

Imagine um projeto que use Hibernate + EJB + VRpator + Sttela....(só um exemplo) ONDE cada um tem suas anotações...acho que esta na hora de mudarmos de idéia...

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

É um problema crônico na área.

Acharam uma coisa legal, que resolvia bem uns certo problemas. Anos depois a tal coisa legal foi aplicada de cabo a rabo para qualquer problema. Resultado: Mer**

As vítimas disso:

XML,
Annotations

Remédios p/ tosse são bons contra tosse, algumas formulas até fazem febre baixar, melhorar de gripe e dores de cabeça, mas definitivamente eles não curam cancer.

Eu mesmo tenho a tendência de fazer a mesma coisa com algo que considero genial. Dias depois vejo a porcaria que fiz p/ todo lado, e outro dia perdido limpando tudo. Bem, só mesmo com a experiência de botar a mão no fogo e se queimar p/ aprender aos poucos.

"Annotatations poluem o código?"

Sim, quando mal-usados.

Imagine um projeto que use Hibernate + EJB + VRpator + Sttela....(só um exemplo) ONDE cada um tem suas anotações...acho que esta na hora de mudarmos de idéia...

Elas em si não são nenhum mal, mas são péssimas quando usadas p/ o que não foram feitas.

Notícias, artigos e o maior fórum brasileiro sobre Java