| Autor |
Mensagem |
|
|
|
http://www.martinfowler.com/eaaDev/uiArchs.html
|
 |
|
|
Eu também acho que a nova edição tá demorando demais...
Pelo menos dá para ver alguns ítens novos nesta apresentação no JavaOne 2006, incluindo muita coisa sobre generics.
|
|
|
|
Numa palestra do Google falaram que a maior parte eh C++, mas tem bastante Java, Python e umas linguagens internas tb.
E, Python "novo e revolucionário"?
|
|
|
|
Abdon wrote:
Se esta é a idéia basica do DI como ela não "refere-se estritamente a criação de instâncias"??
No paragrafo abaixo vc ainda escreveu:
Nanão... DI é uma forma de IoC. Meu event listener do VB é outra forma. Quem faz a injeção (suponho que seja o que tu chamas de auto-wiring) é o container (tanto faz se você usa um conhecido como Spring, PicoContainer, Guice ou se desenvolveu o seu). Ou seja, DI estabelece que seu componente não vai usar um Locator para buscar suas dependências. Em algum momento até que o componente precise de uma dependência, esta será injetada nele. Como se descobre a dependência, instancia, injeta é mais um problema de projeto/implementação.
Um exemplo sem instanciação: o assembler pode buscar a dependência num JNDI da vida e injetar um stub em um componente.
Outra coisa, eu acho que as definições do Saoj nao estao certas. IoC eh uma característica geral (ate definidora, talvez) de frameworks quaisquer. Simplesmente significa que o código do framework vai chamar os seus métodos, e nao o contrario. Como o TheMask disse, isso existe ateh em toolkits gráficos procedurais (onde chamam de "callback").
DI aplica inversion of control para controlar as dependencias dos seus objetos. Ou seja, em vez do objeto (pode chamar de componente se quiser) instanciar direto ou pedir para um locator, ele define um metodo (ou construtor) que sera chamado pelo framework para fornecer estas dependências.
O artigo do Fowler explica tudo isso em detalhes; so nao se preocupem demais em entender Interface Injection ("type 1"), acho que ninguem mais usa isso.
|
|
|
|
Eu tambem estive numa situacao parecida e conclui que uma implementacao estilo procedural era mais adequada para um Mapper que tratava um protocolo de comunicacao.
No inicio pensava numa cadeia de handlers que tratavam de cada passo do protocolo, estilo CoR, mas isso virou um ravioli desgracado. Eu ando pensando que codigo nas bordas de um sistema OO em geral nao se presta muito a uma decomposicao em objetos tradicional; outros paradigmas sao mais proximos da natureza do problema.
|
|
|
|
Paulo Silveira wrote:tem um pessoal de peso la dando aula
Por exemplo? To perguntando por curiosidade mesmo, nao conheco muitos pesquisadores brasileiros em engenharia de software.
|
|
|
|
Luca wrote:
A Microsoft está se mexendo, acorda Sun.
http://weblogs.java.net/blog/mhadley/
http://blogs.sun.com/sandoz/
https://jsr311.dev.java.net/
|
|
|
|
1 - Sim.
2 - Sim. Na faculdade (IME-USP) eu vi Lisp, Scheme e SASL. Por fora eu estudei Scala e Oz (tenho medo de Haskell  )
3 - Certamente. O lado negativo é que eu não consigo trabalhar com coleções em linguagem nenhuma mais sem pensar em map, fold e filter.
4 - Espaço, sim. Se alguma delas será o "próximo Java", não. Na verdade eu espero que no futuro o mercado comporte algumas dezenas de linguagens de programação. But I'm not holding my breath.
|
|
|
|
 100% REST sobre HTTP, com PUT, POST, GET, DELETE, content-types padronizados (e não, application/xml não conta), sem geração de URIs por clientes, suportando e-tags e o c@&@!0 a quatro é excelente. Atompub rules!
Só estruturar seu serviço como recursos (lembrando que o espaço de recursos é potencialmente infinito) também é bom, mesmo se for necessário deixar de lado algumas das restrições REST, p ex, se o serviço não fizer uso de PUT e DELETE ou se depender de formatos de representação não padrões (qq coisa que não passou pelo IETF e não tem um tipo MIME oficial).
Tomando cuidado para evitar violar o HTTP (como o del.icio.us e bloglines fazem) ou botar semântica de ações nas URLs (como o Amazon Web Services faz), até uma solução POX simples é melhor que muita coisa por aí.
PS: Sou ignorante em BBcode, como faz para funcionar a tag [[list]]?
|
|
|
|
Eu gosto muito de REST (acho que já disse isso por aqui antes ), mas POX não é nenhuma porcaria não. Só é preciso tomar cuidado para não botar nenhuma ação que não seja safe e idempotente atrás de um GET.
O Don Box tem escreveu coisas interessantes sobre isso.
|
|
|
|
|
Uma lista
|
|
|
|
cassio wrote:Eu pedi os DVDs do Solaris um tempo atrás, dai veio um pack com 3 DVDs, um para instalar o Solaris em x386, outro para 64bits e outro com um kit de desenvolvimento. Entre outros brinquedos, vem o NetBeans 5.5 no DVD 
Demorou um mês e meio pra chegar mais ou menos...
So para constar, a URL para pedir os DVDs do OpenSolaris eh http://get.opensolaris.org/. Eu tenho alguns destes comigo em Sao Paulo se alguem tiver muita pressa e puder passar na USP para pegar. Mas os que eu tenho ainda sao do SX-CE build 50, e nos builds mais novos tem muita coisa legal, especialmente a tal "developer edition" que ja vem com Sun Studio, Netbeans, Solaris CoolStack, etc, etc... Tudo de graca, obviamente.
PS: Se os moderadores acharem que o caráter desta mensagem eh muito comercial, podem apagar.
|
|
|
|
pcalcado wrote:
AllMighty wrote:Eu estou aqui a trabalho, entao acabei assistindo poucas apresentacoes, mas a organizacao (e o coffee break) parecem bem melhores do que em 2005. Do GUJ, soh encontrei o pcalcado, mas nao conheco a fisionomia da maioria do pessoal daqui.
Encontrou? Onde? Falou comigo? Onde? 
Falei sim, acho que nao sou muito memoravel, Eu tava na reuniao com o Rich Green como Sun Campus Ambassador.
Outra coisa, voces tem sugestoes para melhorar o evento? Que tipo de palestras voces achariam mais legal?
|
|
|
|
|
Eu estou aqui a trabalho, entao acabei assistindo poucas apresentacoes, mas a organizacao (e o coffee break) parecem bem melhores do que em 2005. Do GUJ, soh encontrei o pcalcado, mas nao conheco a fisionomia da maioria do pessoal daqui.
|
|
|
|
|
Para uma visão do "outro lado", assistam a excelente apresentação do próprio Stefan Tilkov no Parlays.com sobre REST.
|
|
|
|