| Autor |
Mensagem |
|
|
x@ndy wrote:
mochuara wrote:Sim, vc esta enganado. Eu não disse que objetos valor devem ser imutáveis, eu disse que para eles serem compartilhados, precisam ser imutáveis.
Bom não li isso que você disse em nenhum lugar, mas mesmo assim me desculpe então.
Está implicito, ser compartilhado livremente é uma das grandes maravilhas dos objetos valor.
x@ndy wrote:
Bom, agora estamos tratando de outra questão pelo jeito, pois primeiro você disse que não era possivel ter em um Objeto Valor uma Entidade, agora você diz que não é viável para o projeto! Então vamos lá:
Ah novamente, me desculpa, eu achei que estavamos falando de DDD no mundo real, e não em exemplos de livro.
x@ndy wrote:
1º) A forma como as classes se relacionam são guiadas pelo domino e não por mim, ele me impõem as regras e não o contrário!
2°) Não sou eu que cria regras para "copiar" objetos isso depende justamente do dominio da aplicação e o próprio Evans fala sobre isso em seu livro!
Se seu objeto é mutavel (e entidades são mutáveis) elas podem ser alteradas por outras threads. Se seu objeto valor depende de atributos da entidade (e certamente dependerá) então vc pode ter bugs no seu sistema, a não ser que use locks!
Imagine que a Rota fornece sua distancia. Ela depende do atributo marcoZero de cada cidade. Se qualquer um pode alterar o marcoZero da cidade, não seria um risco depender da acuracidade de Rota.getDistancia()?
|
 |
|
|
esmiralha wrote:
Que grande malabarismo é esse??? Prover um método fábrica estático que receba um objeto da própria classe? Muito barulho por nada...
Seu exemplo que não mostra nada, que Rota mais sem graça. 
Se algumas das Cidades forem alteradas sem Rota saber não vai acontecer nada, porque Rota não faz nada com as Cidades, o que vc quer provar com esse exemplo?
|
|
|
|
esmiralha wrote:Eu prefiro comunicar aos desenvolvedores uma heurística simples para garantir que um objeto seja imutável, do que dizer para eles que um VO não pode referenciar diretamente uma Entidade e ter que mudar o domínio para atender a uma regra.
Se uma Rota começa em uma Cidade e termina em outra Cidade, que seja. Não vou referenciar PKs ao invés da própria Entidade, nem criar uma Entidade se Rota é um VO.
E que heuristica simples seria essa? Se for aquela de copiar objetos sinto lhe dizer, mas não funciona, além de não ser nada simples (como se diferencia objetos copiados de não copiados?). 
|
|
|
|
x@ndy wrote:
Agora se a rota depende de algum atributo dessa rodovia, digamos de um acesso, então não devemos permitir que essa rodovia mude, pois se mudar vai quebrar uma invariante do meu objeto rota tornando o mesmo inválido. Como a rodovia é uma ENTIDADE para compartilha-la devemos então fornecer para a rota uma copia do objeto rodovia e não devemos permitir que os atributos dessa cópia sejam alterados.
É claro que Rota depende de atributos da Rodovia que ela contem, senão não faria sentido ela ter uma referencia para rodovia em primeiro lugar. O que não entendo é o seguinte, porque vc acha melhor fazer todo esse malabarismo de copiar objetos, impedir que a entidade seja alterada(!), se vc pode simplesmente possuir o id dessa Rodovia e o cliente da Rota (um service por exemplo) usar o Repositório para acessar a Rodovia quando ele achar melhor?
Resumindo, porque complicar?
|
|
|
|
x@ndy wrote:
Dando continuidade, me corrija se eu estiver enganado, mas o primeiro problema que eu vejo com seu ponto de vista é que você acredita que um OBJETO VALOR tem que ser obrigatoriamente imutável, o que está errado! O objeto valor tem que ser imutável apenas se for compartilhada uma referencia sua com outro objeto! Se eu não quiser, ou não puder torná-lo imutável e desejar compartilha-lo, posso fazer isso mediante uma cópia do mesmo! E se esse OBJETO VALOR não for compartilhado não é necessário sequer torná-lo imutável (não que isso não seja uma boa prática)
Sim, vc esta enganado. Eu não disse que objetos valor devem ser imutáveis, eu disse que para eles serem compartilhados, precisam ser imutáveis.
Por outro lado, para atingir o mesmo objetivo, vc tem que usar um monte de regras como "se o atributo X do objeto Y for importante para o objeto Z então faça isso", que todo mundo sabe, não escala para um projeto real. Como vc comunica esses pecualiridades com os outros membros da equipe? Vcs não deveriam estar conversando sobre o dominio usando a linguagem do negócio ao inves de estarem criando regrinhas de como copiar objetos?
|
|
|
|
|
Qual a versão do android do seu amigo? E do iphone?
|
|
|
|
|
Bom, se eles vao mesmo usar html vou esperar pra ver, melhor do que perder tempo reescrevendo meu app depois.
|
|
|
|
drigo.angelo wrote:Ah sim... ainda não desenvolvo app mobile (nem mesmo jme) então fico fora dessas brigas, que, aliás acho bobeira ficar falando de fanboy da apple, ou fanboy do android.. eu mesmo ainda tenho vontade de aprender os 2 
Gosto muito dos produtos da apple, dá pra notar que eles se preocupam muito com qualidade/usabilidade, e gosto da google também, não vejo motivo de tanta disucssão.. 
E o post não ficou agressivo, apenas ta mostrando a notícia...
Claro, qualquer iniciativa mobile de sucesso vai ter que em algum momento portar para android e outros. Mas é que tem gente que é devota do sao google e nao aceita que ninguem fale mal das porcarias que o google eventualmente poe no mercado.
|
|
|
|
A oracle nao quer o fim do android, e sim receber uma grana sobre cada device android vendido pelo possivel uso de sua tecnologia.
Se for este o caso, traria serias implicacoes para o futuro da plataforma android. Primeiro que o google nao contava em pagar esse extra, e se ela repassar os custos, como foi sugerido aqui, android perderia em muito seu grande diferencial que é ser gratuito para os fabricantes.
O importante é que mesmo que cheguem a um acordo, o futuro do java no android e incerto, todos sabem da preferencia do google por tecnologias web, o processo da oracle pode acelerar a transicao para uma plataforma baseada em html, ao inves de java.
http://guj.com.br/java/231236-gerente-da-plataforma-android-diz-que-java-e-degrau-para-futuro-baseado-em-html
|
|
|
|
drigo.angelo wrote:
j0nny wrote:E ainda não gosta de ser chamado de Apple-fanboy, vai entender
????
boiei
Qualquer um que posta noticia sobre a area mobile que nao agrada os fandroids sao taxados de fanboy da apple.
Mesmo que a noticia seja do proprio funcionario do google, responsavel pelo android! 
|
|
|
|
boone wrote:Mãe, criei um tópico !
Se o futuro do google para android é mesmo HTML e nao java, ate minha mãe vai criar apps.
parece que no futuro fandroids terao que recorrer a apple se quiserem ganhar dinheiro com desenvolvimento de apps.
|
|
|
|
nofan wrote:Na nossa perspectiva como desenvolvedores android é java o que é discutido é se legalmente ele o é.
Porque android é java.
Utiliza os pacotes java que usamos no desktop como java.util, java.sql, java.io etc
Utiliza pacotes desktop de classes java da apache como org.apache.http
Tem as mesmas bases na maquina virtual.
Agora legalemente coisa que não interessa a mim como programador exceto pra bate boca no guj cabe a oracle e ao google decidirem o que sera ja que so podemos ter acesso a especulações.
Desculpe, mas sua perspectiva nao importa, e sim a do Google, e para eles android nao e Java.
O processo Google x Oracle nao é para descobrir se android e java, e sim se android possum album codigo de propriedade da oracle sendo usado no produto do google.
|
|
|
|
|
Antes de mais nada, nao tem nada no opensource que impeça de cobrar licença. Portanto eles podem muito bem manter o Java aberto e cobrar um prêmio por servicos ou produtos relacionados ao Java. Mas cobrar do zezinho que esta desenvolvendo na ponta? Acho que nao rola.
|
|
|
|
Em evento na Califórnia e logo apos a apple anunciar 10 bilhões de downloads na sua AppStore, gerente da plataforma android Chu diz que a empresa nao esta feliz com o fraco desempenho do android market, e ainda comenta que o Google aposta no HTML5 para criar apps, deixando claro que a empresa não vê java no futuro do Android.
http://www.appleinsider.com/articles/11/01/26/google_not_happy_with_slow_android_app_sales.html
|
|
|
|
Em evento na Califórnia e logo apos a apple anunciar 10 bilhões de downloads na sua AppStore, gerente da plataforma android Chu diz que a empresa nao esta feliz com o fraco desempenho do android market, e ainda comenta que o Google aposta no HTML5 para criar apps, deixando claro que a empresa não vê java no futuro do Android.
http://www.appleinsider.com/articles/11/01/26/google_not_happy_with_slow_android_app_sales.html
|
|
|
|