Trazer dados de um VO

Não entendi direito o teu problema, se vc tem um VO preenchido basta acessar os gets do mesmo para ver os valores… vc não tem mais a referência dele? está usando algum framework? tem como postar alguma parte do código?

Deixa eu tentar explicar a confussão que eu fiz. Tinha um VO com os dados q eu precisa manipular, só que entre as classes que eu estava chamando pra manipulação de dados eu não estava passando como parametros o VO em sua chamada de metodo e por isso quando eu tentava dar um get de alguma variavel do VO acaba trazendo um VO nulo.
Deu pra entender??? …rsrs Acho que nem eu consegui entender … o importante é que funcionou.

Yataaaa!!!

Imagino q o problema q vc estava enfrentando tenha sido este mesmo.
mas tens que tomar cuidado para nao instanciar outro objeto.

Por que você está usando um TO (antigo VO) em primeiro lugar?

Eu usei bastante esse pattern até recentemente. Este Pattern foi, no passado, bastante utilizando e ensinado em literaturas e revistas. Ainda tenho muitas revistas com exemplos.
No entanto, olhando hoje -2008- para POJOs, DDD, TDD e etc, etc., percebe-se que tornou-se absoleto.
Mas, encontra-se muitos exemplos por ai…

Percebo que, você costuma pegar pesado com os caras quando cita TO, VO, DTO…

Eu não acho que eu pegue pesado, eu apenas pergunto: qual a motivação? Todo pattern é acompanhado de uma motivação. Usar TO só porque viu num exemplo, sem saber porque, nao me parece uma coisa lá muito saudável.

E não é de agora que este tipo de coisa acontece. Desde sempre que existe uma motivação por trás do Transfer Object.

pcalcado:

Eu não acho que eu pegue pesado, eu apenas pergunto: qual a motivação? Todo pattern é acompanhado de uma motivação. Usar TO só porque viu num exemplo, sem saber porque, nao me parece uma coisa lá muito saudável.

E não é de agora que este tipo de coisa acontece. Desde sempre que existe uma motivação por trás do Transfer Object.

É compreensível a sua visão. No entanto, temos que considerar que, existem os “formadores” de opinião. E, estes, estão escrevendo e mostrando exemplos em livros e revistas. Que o diga Martin Fowler, Rodrigo Yoshima, Phillip Calçado e muitos outros (inclusive a própria Sun com seus BluePrints), só para citar alguns.

No entanto, para quem está começando e/ou tem pouco experiência no assunto desenvolvimento, principalmente, OO, acaba tomando como regra exemplos destes escritores. E, como muitos exemplos são bastante focados em determinados contextos - o que é normal -, a coisa acaba se tornando uma confusão completa, pois, a abstração não é lá muito trivial. Isso acontece porque, muitos, querem impor sua opinião ao mundo e estes desejam que tenham bastante seguidores.

Por exemplo, veja a confusão que criaram quando uma literatura falou em VO, outra falou TO, outra em DTO, onde, no fundo, acaba sendo a mesma coisa, com pequenas diferenças conceituais criadas pelo pai da criança. Hoje o povo está confundido, DAO, Repository, DataMapper etc. Por que isso é acontece? Porque no mundo da arquitetura abstrata, a NOMENCLATURA torna-se uma exigência quando conceitos são criados. E assim, acaba se tornando complicado - tanto para o escritor como para o leitor principalmente - abstrair a coisa conforme o contexto da aplicação, a partir no mundo OO que a pessoa está vivenciando no momento.

Eu não entendi exatamente o seu ponto.

A nomenclatura é importante mas está longe de ser a causa do problema. Seja a bibliografia que fala VO, TO ou DTO todas elas possuem as motivações para uso. Eu concordo que não seja simples assimilar conceitos, o problema é que um desenvolvedor que usa qualquer coisa sem procurar saber porque o faz não está cumprindo o que é esperado dele.

Falando especificamente em padrões eu nunca li um texto de referência sobre estes que não citasse a motivação para seu uso, logo eu tendo a assumir que a pessoa não leu a descrição da técnica que está usando com a atenção requerida. Se a impressão que o iniciante teve, por qualquer motivo que seja, foi errada, nunca é tarde ou cedo demais para que o conceito seja revisto e um fórum técnico como o GUJ é uma ótima oportunidade.

pcalcado:

Eu não entendi exatamente o seu ponto.

Conceitos mudam (evoluem?), mas conceitos básicos como estes não mudam tão constantemente assim a ponto de prejudicar o entendimento.

Eles não são parecidos, são a mesma coisa. (se você conta VO como o do Core j2EE Patterns)

O que mudou foi o nome. Core J2EE Patterns 1a edição, Core J2EE Patterns 2a edição e POEAA divergem dos nomes mas o conteúdo é o mesmo. Como saber porque eles têm nomes diferentes? Uma busca bem intuitiva no Google te dá vários textos:

http://www.google.com/search?q=diferenca+vo+dto+to

E um POJO é algo bem diferente dos outros citados, simplesmente porque ele trata de algo diferente. Você pode ter DTOs POJOs. Os resultados da busca acima também trazem respostas sobre isso.

E se todos os envolvidos na discussão concordarem em chamar um DTO de ‘banana d’água’ isso não causaria o problema de modelos anêmicos/excesso de DTOs que temos. Por mais importante que o nome seja ele não interfere diretamente na motivação para usar um pattern destes.

Resumindo: Para mim o problema é que após o primeiro “Ah, entendi” boa parte das pessoas nunca revisita aquele conceito e perde a oportunidade de ver que o que entendemos de primeira não é necessariamente o conceito correto/mais apropriado. A consulta que linkei acima tem 1,380 resultados e logo o primeiro deles (link pro GUJ, aliás) já define todos os termos.

pcaldo
[“logo eu tendo a assumir que a pessoa não leu a descrição da técnica que está usando com a atenção requerida.”]

Cara eu tenho uma duvida, como o amigo ai disse é complicado agnt poder se basear em um buscador até porque agnt acaba lendo um monte de coisas e não tem uma referencia certa do tipo de pattern a utilizar. Existe algum lugar onde podemos ler algum tipo de descrição técnica dos patterns que poderemos utilizar para desenvolver alguma coisa de maneira confiavel?

Mais uma vez grato pela ajuda.

A melhor maneira, na minha opinião:

1 - João diz para José “Você deveria usar o pattern XYZ”
2 - José digita “XYZ Pattern” no google e descobre que ele foi definido pelo Arnaldo no livro ABC
3 - José consegue uma cópia do livro ABC e lê a descrição do Pattern
4 - José fica com dúvida se esta é a melhor saída e pergunta no GUJ
5 - José decide se é uma boa escolha

Busque ler a referência sobre o material. Com uns três livros você já tem uma biblioteca que cobre 90% dos padrões mencionados no GUJ, por exemplo.

pcalcado:

Eles não são parecidos, são a mesma coisa. (se você conta VO como o do Core j2EE Patterns)
O que mudou foi o nome. Core J2EE Patterns 1a edição, Core J2EE Patterns 2a edição e POEAA divergem dos nomes mas o conteúdo é o mesmo.

Não vejo diferenças. Essencialmente é a mesma coisa. Quando alguém procura por POJO encontra isso:

Isso resume o que disse no antepenúltimo post, ou seja, nomenclatura.

Quando se procura por DTO, acaba-se normalmente encontrando isso:

Isso também resume o que disse no antepenúltimo post, ou seja, os escritores (com seus interesses), e seus seguidores.

Quero deixar claro que, não estou querendo fazer oposição a nenhum escritor e/ou conceitos/nomenclatura, muito pelo contrário. Apenas acredito que, tudo que a pessoa precisa entender é de OO. Patterns, deve-se conhecer, bem como seus conceitos. E você utiliza-os da maneira que achar mais adequado no momento e ambiente que se encontra. Por exemplo, tem empresa que prefere trabalhar com scriptlets puro (tudo dentro de uma única JSP) e conheço uma delas. Ai…, vai querer inventar uma “arquiteturinha” para você ver…

pcalcado:

Busque ler a referência sobre o material. Com uns três livros você já tem uma biblioteca que cobre 90% dos padrões mencionados no GUJ, por exemplo.

Esse negócio de adotar padrões sem saber porque é comum.

Há cerca de uns dois anos atrás começaram a trabalhar com java na empresa onde trabalho (não estava aqui na época). Nenhum dos presentes tinha visto qualquer coisa sobre arquitetura em java antes. Viram em uma revista um artigo onde o infeliz do autor colocou as regras de negócio em alguma coisa chamada “service” e imitaram o DAO e VO de outra empresa. Resultado: uma arquitetura horrível.

O negócio é esse. Se na revista, ou na empresa XYZ, o fulano usou uma coisa chamada A e outra chamada B, quem não entende nada, entende muito pouco ou pensa que entende vai acabar imitando. “Se lá dá certo e fazem assim, devemos fazer aqui também”.

Concordo.
Ai… vai o recém contratado, querer mudar a cultura da empresa…
De novo, “programar” conforme a música.

Acho que você precisa rever alguns conceitos, como falei antes. DTO/VO/TO é um design pattern, uma solução para um problema específico. POJO é apenas um nome para chamar objetos que não são EJBs, não são Servlets, etc., basicamente objetos que não estão sujeitos à estender nem implementar interfaces de algum framework ou biblioteca.

A wikipedia não é exatamente a melhor fonte sobre padrões mas eu me pergunto porque você acha que essa definição é a mesma coisa do que a de DTO. o que eles têm de semelhante?

Isso resume exatamente o que? Como falei antes existem diversos nomes mas o conceito é o mesmo, e pior: um artigo referencia o outro. Se você tem um motivo para colocar ele no seu sistema pouco importa do que você chame, agora o problema de usar um padrão fora de contexto não é nomenclatura já que, seja lá qual autor (e seus “interesses”) você escolha vai estar uma lista de motivações para usar o padrão. Quer usar o padrão fora de contexto? Ótimo, use mas não ache estranho de descrever sua arquitetura num fórum público (ou mesmo dentro da sua organização) e ela ser questionada.

E existe empresa que programa em Access e ASP 3.0 para a web. Por isso você vai usar? E o que você quer dizer com isso tudo? Que se deve usar TO quando for necessário? E eu falei algo diferente disso em algum momento? Pelo contrário, eu falei que o problema é exatamente quando se usa sem necessidade (que é a enorme maioria dos casos).

E, desculpe, mas usar TO fora de contexto é um sintoma gravíssimo de que não se entende de Orientação a Objetos, logo eu continuo sem entender onde você quer chegar.

victorwss:

Esse negócio de adotar padrões sem saber porque é comum.

Há cerca de uns dois anos atrás começaram a trabalhar com java na empresa onde trabalho (não estava aqui na época). Nenhum dos presentes tinha visto qualquer coisa sobre arquitetura em java antes. Viram em uma revista um artigo onde o infeliz do autor colocou as regras de negócio em alguma coisa chamada “service” e imitaram o DAO e VO de outra empresa. Resultado: uma arquitetura horrível.

O negócio é esse. Se na revista, ou na empresa XYZ, o fulano usou uma coisa chamada A e outra chamada B, quem não entende nada, entende muito pouco ou pensa que entende vai acabar imitando. “Se lá dá certo e fazem assim, devemos fazer aqui também”.

Exato, e comunidades como o GUJ existem exatamente para que as pessoas aprendas juntas e melhorem seu entendimento e não para advogar este tipo de arquitetura ctrl-v+ctrl-v .

pcalcado:

Acho que você precisa rever alguns conceitos, como falei antes. DTO/VO/TO é um design pattern, uma solução para um problema específico. POJO é apenas um nome para chamar objetos que não são EJBs, não são Servlets, etc., basicamente objetos que não estão sujeitos à estender nem implementar interfaces de algum framework ou biblioteca.

pcalcado:

A wikipedia não é exatamente a melhor fonte sobre padrões mas eu me pergunto porque você acha que essa definição é a mesma coisa do que a de DTO. o que eles têm de semelhante?

pcalcado:

Ótimo, use mas não ache estranho de descrever sua arquitetura num fórum público (ou mesmo dentro da sua organização) e ela ser questionada.
Isso resume exatamente o que?

pcalcado:

Como falei antes existem diversos nomes mas o conceito é o mesmo, e pior: um artigo referencia o outro…

pcalcado:

Se você tem um motivo para colocar ele no seu sistema pouco importa do que você chame, agora o problema de usar um padrão fora de contexto não é nomenclatura já que, seja lá qual autor (e seus “interesses”) você escolha vai estar uma lista de motivações para usar o padrão. Quer usar o padrão fora de contexto? Ótimo, use…

O ponto é que temos que ter o conhecimento do todo e adapatar conceitos. Isso vale para qualquer coisa, inclusive metodologia. Você ler livros, faz cursos e, aprende o jeito certo de usar XP, SCRUM com os “pais” das crianças. Mas quando você chega na empresa XYZ, os “caras”, usa XP e SCRUM do jeito deles, pegando isso ou aquilo, adaptando uma coisa ou outra e, pronto. O novato tem que se enquadrar. Você mesmo sabe disso.

pcalcado:

Ótimo, use mas não ache estranho de descrever sua arquitetura num fórum público (ou mesmo dentro da sua organização) e ela ser questionada.

pcalcado:

Isso resume exatamente o que?

Se amanhã ou depois o M.F. dizer em uma bibliografia: “vejam… no passado eu chamava isso de POJO, mas hoje, com a introdução desta nova interface o qual chamei de RETAL, passarei a chamá-lo de LOVORE…”. Pronto. Todos os seus seguidores dirão: “Amém!” E, passarão a ensinar o tal de LOVORE nos seus blogs e justificarão isso, mais aquilo… ai logo venha a JM, e bota na capa: “PROGRAMANDO COM LOVORES”. Qual a diferença de um livro que diz: “Programando com POJO” de outro que diz: “Programando com Java”? Essencialmente, o que o autor está querendo ensinar é OO e nada mais, além de querer criar novos conceitos e/ou arquiteturas para ter seguidores e ganhar seu “dinheirinho”.

pcalcado:

E existe empresa que programa em Access e ASP 3.0 para a web. Por isso você vai usar? E o que você quer dizer com isso tudo? Que se deve usar TO quando for necessário? E eu falei algo diferente disso em algum momento? Pelo contrário, eu falei que o problema é exatamente quando se usa sem necessidade (que é a enorme maioria dos casos).

jmoreira:

Veja, o que é um DTO/VO/TO/POJO para mim não é o ponto e, faz-se desnecessário, as explicações sobre o que é isto ou aquilo. Isso já foi bastante discutido em tópicos anteriores.
O que levantei foi a similaridades entre estes objetos/conceitos/nomenclatura. São muitos sutis quando a prática entra em campo. E, para quem está começando, ler 3, 4, 5 livros ? como você disse - para entender a diferença entre DTO/VO/TO/POJO é um exagero. Não faz sentido isso.

E eu estou discordando de você de que eles são parecidos (os 3 primeiros são a mesma coisa, o último é um conceito completamente diferente) e você não precisa de 3 livros para entender isso, anteriormente eu postei uma consulta no google que te dá a resposta.

Nem POJOs nem DTOs precisam necessariamente de nada acima. O que você descreveu me parece o que é comumente chamado de JavaBean, este sim bem confundível com POJO.

Ok mas eu espero que ninuém fique iniciante para sempre e que no processo de aprendizagem ele procure saber mais sobre as coisas. Se nos primeiros projetos aluém usa um padrão de forma inapropriada não há problema, o problema é não aprender mais sobre sua própria profissão.

Quer dizer que se eu não entendi o que você disse imediatamente a culpa é minha por não prestar atenção? Interessante…

jmoreira:

Nisso entra o que já foi dito. Muitos tomam por regra aquilo que deveria ser abstraído das bibliografias e acabam usando certos conceitos em contextos diferentes, mas que para aquele, ou, aquela empresa, aquilo tem resolvido os problemas e sempre irão resolver. É ai que, entra o meu ponto, ou seja, o que o cara deve entender é de OO, o resto, o cara terá que adaptar, pois, na empresa X, os “caras” chamam DTO de VO; Na Y, VO de POJO; na Z, POJO de BOVO e por ai vai.

O ponto é que temos que ter o conhecimento do todo e adapatar conceitos. Isso vale para qualquer coisa, inclusive metodologia. Você ler livros, faz cursos e, aprende o jeito certo de usar XP, SCRUM com os “pais” das crianças. Mas quando você chega na empresa XYZ, os “caras”, usa XP e SCRUM do jeito deles, pegando isso ou aquilo, adaptando uma coisa ou outra e, pronto. O novato tem que se enquadrar. Você mesmo sabe disso.

Sim, sei, e não discordei disso -pelo contrário.

E quando é que eu falei que você descreveu uma arquitetura? Estou falando se acontecer o que aconteceu, diamos, com o autor original deste tópico.

jmoreira:

É difícil entender o raciocínio dos outros quando, a agente só entende e enxerga apenas os nossos.

Ok, mais uma interessante: eu não entendi o que você quis dizer == eu enxergo apenas o meu raciocínio. Bem assertivo.

jmoreira:

Quando o cara diz: “MUITAS pessoas usa isso neste sentido… mas EU uso para significar isso…”, o que ele está querendo fazer? Formar opinião? Criar novos conceitos? Fazer adaptação? Não sei. Só sei que muitos embarcarão com ele. Isso é fato.

Se amanhã ou depois o M.F. dizer em uma bibliografia: “vejam… no passado eu chamava isso de POJO, mas hoje, com a introdução desta nova interface o qual chamei de RETAL, passarei a chamá-lo de LOVORE…”. Pronto. Todos os seus seguidores dirão: “Amém!” E, passarão a ensinar o tal de LOVORE nos seus blogs e justificarão isso, mais aquilo… ai logo venha a JM, e bota na capa: “PROGRAMANDO COM LOVORES”. Qual a diferença de um livro que diz: “Programando com POJO” de outro que diz: “Programando com Java”?

E o que tem isso de diferente com o que -como você mesmo notou- eu venho repetindo neste tópico?

Não, nem tudo é Orientação a Objetos. DTOs, por exemplo, não são -são arquiteturas de sistemas.

Então você defende que mesmo sem necessidade um padrão seja usado porque “sempre foi assim”? Onde entra evolucão e inovação nisso? Pensando assim não estaríamos programando em COBOL para sempre, já que muitas empresas possuem “um monte de coisa funcionando” em COBOL há décadas?

Eu acho que entendo agora o cerne do seu argumento: nem só de escolhas técnicas se baseia uma arquietura. e eu estiver correto neste entendimento eu tenho que perguntar: e onde eu teria discordado disso?

pcalcado:

E eu estou discordando de você de que eles são parecidos (os 3 primeiros são a mesma coisa, o último é um conceito completamente diferente) e você não precisa de 3 livros para entender isso, anteriormente eu postei uma consulta no google que te dá a resposta.

pcalcado:

… Busque ler a referência sobre o material. Com uns três livros você já tem uma biblioteca que cobre 90% dos padrões mencionados no GUJ…

pcalcado:

Nem POJOs nem DTOs precisam necessariamente de nada acima.

pcalcado:

O que você descreveu me parece o que é comumente chamado de JavaBean, este sim bem confundível com POJO.

pcalcado:

Quer dizer que se eu não entendi o que você disse imediatamente a culpa é minha por não prestar atenção? Interessante…

pcalcado:

E quando é que eu falei que você descreveu uma arquitetura?

pcalcado:

Não, nem tudo é Orientação a Objetos. DTOs, por exemplo, não são -são arquiteturas de sistemas.

pcalcado:

1) Ok, onde eu contrariei isso?

pcalcado:

2) Creio que concordemos que isso não quer dizer que um profissional deve limitar seus conhecimentos à XPTO, logo qual o problema em entender ou procurar entender como aquela arquitetura poderia ser diferente?

jmoreira:

… Patterns, deve-se conhecer, bem como seus conceitos. E você utiliza-os da maneira que achar mais adequado no momento e ambiente que se encontra…

pcalcado:

Então você defende que mesmo sem necessidade um padrão seja usado porque “sempre foi assim”? Onde entra evolucão e inovação nisso? Pensando assim não estaríamos programando em COBOL para sempre, já que muitas empresas possuem “um monte de coisa funcionando” em COBOL há décadas?

pcalcado:

Eu acho que entendo agora o cerne do seu argumento: nem só de escolhas técnicas se baseia uma arquietura. e eu estiver correto neste entendimento eu tenho que perguntar: e onde eu teria discordado disso?

Agora, para concluir, acredito que essa discussão sobre arquitetura no mundo do desenvolvimento é uma coisa similar a discussão sobre religião e futebol. Na maioria das vezes, fica cada um com seus sentimentos, impressões, opiniões e suas arquiteturas.

Sabe, existe uma diferença bem grandinha entre um conceito (POJO, que nem pattern é) + [b]um padrão /b e 99% dos padrões mencionados no GUJ. Creio que você distorceu tremendamente o que eu disse para poder falar “além de não me ler se contraria” mas é claro que eu estou errado. Talvez além de não saber ler eu não saiba escrever.

Esta bem claro para mim que você não adicionou nada de novo nos seus comentários que já foram questionados, e estamos sendo os dois repetitivos. Como além de não acrescentar nada você está bem agressivo -faltando pouco para me chamar de bobo e feio- eu fico por aqui nesta thread, ao menos com relação a esta assunto que até agora eu nem sei do que se trata já que -tirando sua opinião sobre os conceitos que contraria todas as bibliorafia sde referência- você não me mostrou onde que eu digo para usar ou não usar algo independente da situação.

pq dão tanto enfase a nomeclatura das coisas?
e pq 3 nomeclaturas diferentes para a mesma coisa?
DTO, VO, TO pra mim e td a mesma coisa…
não entendo pq dar tantos nomes aos bois…

e pq separar a nomeclatura de POJO dos demais TOs, VOs e os outros milhares de Os que tem porai so pq ele não extende e implementa classe alguma? pra mim deveria ser a mesma coisa pois servem para a mesma coisa… transportar valores de um lugar para outro…
então deveria ter um unico nome… essa salada de nomes so serve para confundir iniciantes e complicar mais as coisas… isto q é um saco nestes negocios de patters cada neguinho da o nome pro boi diferente… fodase o nome tenque ver sua utilidade se isto e o melhor a ser utilizado na sua necessidade ou não… o nome pouco importa…

Esse é o ponto: eles não servem para a mesma coisa. Um POJO é um conceito e os demais são padrões. Os padrões, como você falou, servem para transportar valores mas o POJO é apenas um nome criado para se referenciar a uma arquitetura que não exige que você estenda nem implemente nada.

Hoje em dia, com EJB 3 que são POJOs, é muito mais difícil ver a diferença mas na época do EJB 2.1 você basicamente escolhia entre usar um EJB ou um POJO para criar uma classe de negócio. Outro lugar importante onde POJOs aparecem é em frameworks MVC. A maioria dos frameworks modernos não exige que sua Action tenha qualquer qualidade especial, eles conseguem lidar com POJOs. O Struts 1, por exemplo, exige que sua Action estenda uma classe do framework e ao fazer isso você deixa de ter POJOs.

Um POJO não serve para transportar dados. Você pode ter trnasportadores de dados, objetos utilitários, objetos de negócio, actions MVC ou praticamente objetos com qualquer responsabilidade que são POJOs. O que faz dele um POJO -ao contrário do DTO- não é sua função e sim sua hierarquia.

Um DTO pode ser um POJO ou não. Se ele for um POJO ele não estende nem implementa nada de framework nenhum, é apenas um classe Java que você criou. Se ele precisa estender ou implementar uma interface de algum framework (algo na linha “class MeuDto extends AbstractDtoDoFrameworkX”) ele deixa de ser um POJO.

[editado]
Alias, pergunta: por que você ficou com a idéia de que POJO e DTO é a mesma coisa?

entendi… então o certo seria : um dto pode ser um pojo mas nem todo o pojo é um dto…
mas pq tantos nomes como: dto, to, vo para algo q tem a mesma fução?

luistiagos:

mas pq tantos nomes como: dto, to, vo para algo q tem a mesma fução?

Eu fale em algum post acima: a Sun chamou de VO no primeiro livro. Quando o Martin Fowler foi falar deste padrão no livro dele ele encontrou um problema: ele já chamava um outro padrão de Value Object. Então ele usou o nome Data Transfer Object -que faz mais sentido.

A Sun, na segunda edição do seu livro, resolveu “aceitar” o ponto do Martin e VO virou Transfer Objet (só não me pergunte porque não virou DTO de vez, não tenho idéia).

Exatamente. Essa é a pegadinha da trabalhar com Java, OO, etc… vc tem que estar atento a essas ondas de “novidade” do “mercado”. Que não significam nada além do que vc já sabia. Esse exemplo que vc deu aconteceu de fato quando o Martin Fowler reutilizou o nome “Value Object” para significar uma coisa diferente do que significava até então. Ele pôde fazer isso, mas experimente dizer alguém que o que ele chama de X é o conceito de Y. A casa cai na hora.

Veja, acho que o problema, é que, você tende a questionar TUDO que os outros falam, sem tentar entender o ponto das questões, na visão pessoal de quem fala. Lá no inicio da thread, você levantou a questão da motivação para usar algo. Eu tentei mostrar que a motivação, muitas vezes está relacionada ao que as bibliografias pregam como ponto principal no meu argumento. Ai você pega outra coisa, neste caso foi a diferenciação entre pattern, conceito e arquitetura e começa a fazer uma série de questionamentos desnecessário ao ponto inicial. Você implicou com cara inicial, porque ele falou em algo como BilheteVO (embrião do blá, blá, blá). Em fim… Até entendo que, a visão de um arquiteto - que acompanha tudo do que há na última moda-, muitas vezes não consegue enxergar o que os outros falam. Mas, tudo bem. Deixemos isso para lá.

Quanto à questão de não acrescentar nada, isso vale para ambos, pois tudo que foi dito aqui, já foi extensamente debatido em outros tópicos e fóruns. Assim falar sobre patterns e conceitos seria desnecessário aqui. Tanto que não tentei em nenhum momento, explicar conceitos/arquitetura e somente questionei similaridades. Quanto a minha “agressividade”, peço desculpas se, você sentiu ofendido com alguma coisa. Às vezes, o que é tranqüilo para mim, não é para outros. Estou tentando me policiar nisso.

pcalcado:

A Sun, na segunda edição do seu livro, resolveu “aceitar” o ponto do Martin e VO virou Transfer Objet (só não me pergunte porque não virou DTO de vez, não tenho idéia).

Juro que não entendo essa história dos POJOs. Tudo bem falar que eles são simples objetos como a OO prega, mas por que falar que eles não estendem nem implementam nada? Qual a utilidade de capar o uso de interfaces e polimorfismo?

Quanto a VO, TO, DTO serem a mesma coisa, só concordo se tivermos falando da implementação deles, e talvez se considerarmos somente a história da nomenclatura usada na comunidade Java EE.

Prefiro a nomenclatura do Fowler:

Value Objects:
Objetos que de tão pequenos poderiam se passar por um tipo primitivo da linguagem, caso ela suportasse, como por exemplo um tipo Dinheiro, tipo Intervalo de Datas, tipo Faixa de Valores. Coisas super-simples que formam uma estrutura p/ serem representadas melhor.

Data Transfer Objects:
Objetos gigantes. Servem somente p/ juntarem outros DTOs e outros objetos serializáveis dentro deles para que eles possam ser transferidos via um interface remota, para transferência pela rede entre computadores. O motivo disso é evitar a saturação da conexão pelo excesso de objetos pequenos com um grande overhead nos pacotes, enquanto com objetos grandes você aproveita a conexão melhor.

Ambos podem ser implementados exatamente da mesma forma, mais comumente usando o padrão JavaBean, mas semanticamente são coisas diferentes.

Bruno Laturner:

Juro que não entendo essa história dos POJOs. Tudo bem falar que eles são simples objetos como a OO prega, mas por que falar que eles não estendem nem implementam nada? Qual a utilidade de capar o uso de interfaces e polimorfismo?

Quanto a VO, TO, DTO serem a mesma coisa, só concordo se tivermos falando da implementação deles, e talvez se considerarmos somente a história da nomenclatura usada na comunidade Java EE.

Prefiro a nomenclatura do Fowler:

Value Objects:
Objetos que de tão pequenos poderiam se passar por um tipo primitivo da linguagem, caso ela suportasse, como por exemplo um tipo Dinheiro, tipo Intervalo de Datas, tipo Faixa de Valores. Coisas super-simples que formam uma estrutura p/ serem representadas melhor.

Data Transfer Objects:
Objetos gigantes. Servem somente p/ juntarem outros DTOs e outros objetos serializáveis dentro deles para que eles possam ser transferidos via um interface remota, para transferência pela rede entre computadores. O motivo disso é evitar a saturação da conexão pelo excesso de objetos pequenos com um grande overhead nos pacotes, enquanto com objetos grandes você aproveita a conexão melhor.

Ambos podem ser implementados exatamente da mesma forma, mais comumente usando o padrão JavaBean, mas semanticamente são coisas diferentes.

O conceito de POJO é que eles não extendem e não implementam nada QUE VENHA DE ALGUM FRAMEWORK EXOTÉRICO.

Ou seja, eles podem implementar ou estender o que VOCÊ quiser, como quiser, quando quiser e se quiser. E não estender ou implementar por obrigação de algum framework maluco.

Benefícios/Malefícios de herança a parte, a idéia não é de que eles não estendam ou implementem nada e sim que não o façam com aluma classe/interface de um framework. Imagine que você esteja usando um framework que exige que todas as suas classes de negócio estendam uma classe BaseObjectFromMyFramework. Além de todas as desvantagens de ter seus objetos de negócio acoplados ao framework em questão você ainda dificulta a testabilidade, já que para testar uma classe apenas tem que levar o framework todo.

Dê uma olhada no que coisas como o Cactus têm que fazer para testar EJBs 2.1. Outra boa leitura é o livro do Rod Johnson (“Without EKB”).

Então acho que este seu ponto foi esclarecido anteriormente.

Bruno Laturner:

Ambos podem ser implementados exatamente da mesma forma, mais comumente usando o padrão JavaBean, mas semanticamente são coisas diferentes.

victorwss:

O conceito de POJO é que eles não extendem e não implementam nada QUE VENHA DE ALGUM FRAMEWORK EXOTÉRICO.

Ou seja, eles podem implementar ou estender o que VOCÊ quiser, como quiser, quando quiser e se quiser. E não estender ou implementar por obrigação de algum framework maluco.

SEMANTICA:
A semântica (derivado de sema, sinal) refere-se ao estudo do significado, em todos os sentidos do termo. A semântica opõe-se com frequência à sintaxe, caso em que a primeira se ocupa do que algo significa, enquanto a segunda se debruça sobre as estruturas ou padrões formais do modo como esse algo é expresso (por exemplo, escritos ou falados). Dependendo da concepção de significado que se tenha, tem-se diferentes semânticas. A semântica formal, a semântica da enunciação ou argumentativa e a semântica cognitiva, por exemplo, estudam o mesmo fenômeno, mas com conceitos e enfoques diferentes.