| Autor |
Mensagem |
|
|
Não entendi bem como o Visitor entra na história. Mas achei a falha no meu raciocínio. A idéia é representar melhor o acoplamento natural entre View e Model para evitar que o Model precisasse expor tantos detalhes de implementeção. A solução do Allen Holub para esse "problema" é que os objetos do modelo soubessem se exibir sozinhos. Obviamente isso acarreta uma dificuldade muito grande em fazer várias views para um mesmo modelo.
Eu pensei que se usasse herança múltipla (View filha de Model e da Superview) essa dificuldade não apareceria. Mas é óbvio que o problema ainda existe - um programa rodando com duas views diferentes para o mesmo Model seria tão ou mais difícil de fazer do que com a solução do Holub.
Na verdade eu não vejo nenhum grande problema em estruturar as aplicações do jeito tradicional. Só acho legal considerar alternativas às vezes. E essa minha alternativa de agora está claramente falha...
|
 |
|
|
Eu vi esse esse artigo um tempo atrás. O autor afirma que a separação da apresentação do modelo (como no MVC) é contra os princípios de orientação a objeto. A justificativa é que para os objetos da View saberem mostrar o conteúdo de um objeto eles precisam, de alguma forma, ter acesso aos internals do objeto - violando o encapsulamento. Note que declarar os fields private e criar uma porção de get/set não altera o fato que a implementação está 'vazando'. O autor (Allen Holub) sugere que os objetos tenham a capacidade de se exibir sozinhos.
Quando eu li na primeira vez eu pensei "Tá, violamos um pouco o encapsulamento - e daí? Encapsulamento é uma diretriz, não um axioma irrevogável. A separação View/Model é uma decisão de projeto como qualquer outra".
Eu estou postando esse tópico agora porque me ocorreu um negócio (e porque é sexta-feira e eu não tenho nada melhor para fazer  ). Se pudéssemos usar herança múltipla, a View poderia ter acesso às private parts do modelo, sem obrigar este a se expor públicamente. O acoplamento formalmente seria um pouco maior do que é sem o relacionamento pai/filho entre o modelo e a view. Mas na prática a View já é muito depentente do modelo. O sistema todo ficaria um pouco mais elegante. Por outro lado, herança múltipla é um abacaxi e, além da elegância, não se ganharia muito.
O que vocês acham?
|
|
|
|
|
Tb empaquei no 10...
|
|
|
|
Eu nao gosto muito de discutir politica em forum de tecnologia mas essa me pegou.
Isso não é uma iniciativa do "PT no poder". É um projeto besta de um radical do Piauí.
O absurdo é os piauienses votarem num cara desses para a câmara.
|
|
|
|
A minha mensagem anterior saiu errada porque esqueci que o forum le < > como uma tag.
O que eu queria dizer é que acho que o estereótipo <<type>> é padrão UML para interfaces. A notação do pirulito é uma espécie de atalho. Vou procurar referências para confirmar isso.
|
|
|
|
Não sei se eu entendi bem a pergunta, mas não nesse caso não é só usar o símbolo de classe (a caixa) adornada com o estereótipo <<interface>> ?
Daí vc pode modelar com a interface tudo o que modelaria com uma classe.
|
|
|
|
|
Um schema XSD é, ele próprio, um documento XML. Isso quer dizer que você pode usar DOM ou qualquer outra API genérica capaz de lidar com documentos XML. Eu não conheço APIs especializadas em xml schema, mas talvez você encontre algo por aí que facilite o trabalho.
|
|
|
|
|
Nos códigos em VB nunca faltava um
|
|
|
|
Em java: www.sakaiproject.org (suporta a JSR-168 e usa as APIs do OKI)
Em PHP: www.moodle.org, www.atutor.ca
|
|
|
|
|
As máquinas vão estar em um domínio do windows. Se sim é só configurar as policies no "Active Directory Users and Groups". Se não vc pode rodar o gpedit.msc na estação e configurar como preferir.
|
|
|
|
louds wrote:
Qual a relação com o teu exemplo usando castings com oque estamos discutindo
Isso pode parecer meio óbivo, e é mesmo: quando se usa Cast's explícitos sempre se incorre no risco de uma ClassCastException. Especialmente considerando que Java usa late-binding nas chamadas de métodos.
Na minha opinião o Generics simplesmente ajuda a encontrar mais cedo alguns erros desse tipo. Mas acho que a ajuda não compensa o aumento de complexidade na linguagem. Se fosse uma implementação mais completa (como parece que é a do .net) talvez a balança pendesse para o outro lado.
Voltando ao meu exemplo, eu só quis mostrar que usar cast's sempre é arriscado, mesmo sem generics. E quanto a subverter o sistema de tipos, eu não pensei muito sobre isso, mas acho improvável encontrar esse tipo de erro em sistemas reais. Ainda mais considerando que o compilador dá um warning para esse tipo de coisa.
Enfim, resumindo, eu também não sou muito fã do Generics.
|
|
|
|
louds wrote:
Viu como Generic não tem tipagem forte
Eu não sabia que o javac deixava fazer cast de um tipo parametrizado para ele mesmo com outro parâmetro. Fui testar e ele dá um Warning na linha do cast, mas compila.
Para fazer gerar esse tipo de problema você usou um cast no código. E casts sempre permitem que se subverta a checagem de tipo na compilação. Um exemplo mais trivial:
Eu ainda não vi como o generics torna o java uma linguagem de tipagem fraca...
OBS: Editei mensagem pq tinha apontado a linha errada p a excecao.
|
|
|
|
louds wrote:
Em java se eu fizer:
Não existe forma de subverter isso em tempo de compilação ou execução e guardar algum valor nessa variavel que não seja do tipo String.
E se eu fizer isso?
louds wrote:
O código abaixo pode lançar um ClassCastException:
Mas esse código aqui também não pode lançar um ClassCastException?:
Eu acho que em runtime não se está fazendo nem mais nem menos checagem do que antes. Em tempo de compilação se está, sim, fazendo mais checagem.
Por favor me corrijam se eu estiver errado.
|
|
|
|
Eu acho ruim apenas que eles vão tornar java uma linguagens com tipagem fraca.
Essa eu não entendi. O objetivo do generics é melhorar a checagem estática (em tempo de compilação) dos tipos. O que muita gente acha ruim (inclusive eu) é que é somente esse o objetivo.
E pelo que eu entendi o efeito na performance deveria ser nulo, porque o compilador simplesmente remove os parâmetros de tipo (erasure) e insere os casts nos lugares apropriados. Como alguém disse, é basicamente um "autocasting". E para finalidade tão limitada eles complicaram enormemente a sintaxe da linguagem  .
Uma discussao interessante ocorreu numa série de posts do blog do Bruce Eckel (o autor do Thinking in Java):
http://mindview.net/WebLog
O Neal Gafter (programador do javac) respondeu ao primeiro post do Bruce Eckel:
http://gafter.blogspot.com/
|
|
|
|
|
Essa discussão me lembrou de uma definição de "Programador": dispositivo para transformar café em código fonte.
|
|
|
|