Arquivo Discussoes de Programacao e Tecnologia 
Perguntinha estilo tostines.
Considerando:
pessoa.bebeAgua(copo d'agua);
//ou
copo d'agua.matarSede(pessoa);
Qual a melhor forma de proceder?
Pessoalmente, desconsiderando demais aspectos do “sistema”, tanto faz.
Utilizaria pessoa.bebeAgua(), tem um tom ativo na coisa, soa mais natural .
Existe algum artigo sobre isso?
É só pensar na ação, o copo não vai pra boca sozinho.
Perguntinha estilo tostines.
Considerando:pessoa.bebeAgua(copo d'agua); //ou copo d'agua.matarSede(pessoa);Qual a melhor forma de proceder?
Pessoalmente, desconsiderando demais aspectos do “sistema”, tanto faz.
Utilizariapessoa.bebeAgua(), tem um tom ativo na coisa, soa mais natural .
Existe algum artigo sobre isso?
Hummm.
public class Pessoa{
public void beber(Liquido l){
l.matarSede(this);
}
}
As duas abordagens são possíveis em um mesmo caso (esqueminha mais ou menos semelhante a um Visitor). Mas, o que lhe parece mais intuitivo? (esta resposta vai determinar seu grau de sanidade mental!)
E ajudar a manter a saude mental de quem for trabalhar no seu sistema depois, tentnado entender por que diabos um copo d’agua voou na cara do sujeito 
E ajudar a manter a saude mental de quem for trabalhar no seu sistema depois, tentnado entender por que diabos um copo d’agua voou na cara do sujeito :P
rsrsrsrs… tah certo que até tem nexo o pergunta… pq mexe um puco com modelagem… o exemplo do beber agua é q foi infeliz!!!
Eu discordo…achei esse exemplo muito interessante pra levar pra discussões sobre modelagem de sistemas, porque é intuitivo e dá margem às duas abordagens 
Então vamos tornar as coisas mais divertidas. Se a pessoa ir a um bebedor? :mrgreen:
Acho que seria bém mais difíci modelar caso a pessoa estivesse morrendo afogada e engulisse água contra sua própria vontade! :?
for(;;){
pessoa.beber(liquido);
}
hhhehehehehhe … chama a ambulancia q esse ai ta morrendo afogado . :mrgreen:
@editado:
Se bem que o matarSede colocado dentro do metodo ajuda o cara a sobreviver … :oops:
Eu escrevi:
…,soa mais natural. Essa é a ideia da coisa, ser o mais natural possivel.
Daniel Quirino:
Resposta exata, muito obrigado.
na realidade obreigado pela participação de todos(até mesmo os engraçadinhos :mrgreen: )
Algum link “bom de verdade” pra esse Visitor?
O google eu também conheço :mrgreen: . Dificil é separar o joio do trigo, por isso pedi um artigo “bom de verdade” sobre esse Visitor. Mesmo assim value…
Agua benta do inferno,
Bicho de sete cabeças … rsrsrs
http://www.dofactory.com/Patterns/PatternVisitor.aspx
primeiro e segundo link 
Mas bom mesmo seria um livro!
ressucitando…
isso seria mesma coisa que
cliente.grava()
ou
dao.grava(cliente)
certo?
a abordagem do dao não seria melhor neste caso?
Nao, nao existem camadas aqui, logo nao ha necessidade de um mapeador.
Micrófilo, a pergunta é: quem chama dao.grava( cliente )?
E, afinal, quem bebeu a porcaria da água?
ressucitando…isso seria mesma coisa que
cliente.grava() ou dao.grava(cliente)certo?
a abordagem do dao não seria melhor neste caso?
Aí depende, ser persistido em um banco de dados não é uma coisa natural, teve um tópico aqui que se discutiu sobre a transparência ou não da persistência.
A idéia do ActiveRecord é apenas implificar o trabalho com bancos de dados quando os objetos são iguais as tabelas, se você mexe muito com herança, relacionamentos 1:N e N:N o DAO é uma escolha muito melhor.
Dá uma olhada nesse livro do Fowler que foi nele que apareceu o ActiveRecord:
Então vc não recomenda o uso de DAOs? :shock:
No caso, é meio irrelevante… talvez uma action
PS: eu sei que o este é meu nick, mas me chamem de Rubem
Não acho irrelevante. Na verdade acho que é a coisa mais importante hehe quem manda qual mensagem pra quem.
Comoe xatamente voce chegou a essa conclusao?
Voce nao acha que esta pensando demais em actions? Command eh um padrao, deve ser usaod em casos muito especificos (por exemplo, processar uma requisiçao web e despachar para um objetod e negocio).
Pessoalmente sem um contexto armado ficaria com o cliente.grava(); ,transparente a lot.
O ponto g da coisa é ser claro e lógico, intuitivo, seguir um -padrão- sempre
( não me refiro aos padrões dos designs).
Lipe:
Foi isso que o Daniel Quirino falou, a coisa tem que ser intuitiva, e fazer isso é foda.
Pergunta: No padrão visitor um determinado algoritmo está do lado de fora da classe que o utiliza.O forte do visitor é adicionar funcionalidade, pelo menos pelo exemplo citado pelo Lipe.
Até que ponto é legal fazer essas visitas? Quando “eu não quero um monte de if/else dentro do metodo” não foi muito esclarecedor.
Fica aquele lance de ser intuitivo e manter a coisa simples, “pra manter a sanidade do desenvolvedor futuro”, num foi isso shoes?
Valeu tbm Lipe pelos links, principalmente o do javaworld.com
O shoes é dislexo :?: Ele viev trocand oas lertas. Alguem cria um parser aew :mrgreen:
Hmmm, as coisas estão ficando mais complexas. Vamos introduzir algumas dependências novas aqui.
public interface Bebedouro{
public Liquido acionarBebedouro() throws SemLiquidoException;
}
public class BebedouroEletrico implements Bebedouro{
public Liquido acionarBebedouro() throws SemLiquidoException{
if(! temAgua())
throw new SemLiquidoException("Xii, tá sem água!");
return new Agua();
}
}
public class MaquinaCocaCola implements Bebedouro{
public Liquido acionarBebedouro() throws SemLiquidoException{
if((! temXarope()) || (! temAguaGaseificada()))
throw new SemLiquidoException("Xii, não tem coca-cola!!");
return new CocaCola();
}
}
public class Pessoa{
private void beber(Liquido l){
l.matarSede(this);
}
public void beber(Bebedouro b){
while(estiverComSede()){
Liquido l = b.acionarBebedouro();
beber(l);
}
}
}
Ok, versãozinha bem simplista. Coisas a se melhorar:
:arrow: criar uma interface “Recipiente” e jogá-la no mesmo nível de abstração da interface “Bebedouro”.
:arrow: alterar a classe Pessoa para que ela suporte um método “beber” que aceite um “Recipiente”. Desta forma, mata-se o requisito “ahhh e se fulano quiser beber em um cantil ou de uma garrafa?”.
P.S.: *Daniel divaga: com Ruby isso seria tão mais fácil. Mas até que é divertido fazer isso em Java
Quer saber se a agua eh bebida ou mata asede?
Pergunte pro seu usuario o que faz mais sentido apra ele
O foco da aplicação vai ditar este tipod e coisas. Voce esta fazendo uma aplicaçao principalmente sobre pessoas que bebem agua ou agua que mata a sede de pessoas?
No alvo :mrgreen:
Programador Java vive sofrendo de “Ainda não está complexo o suficiente”.
Phillip, aindo estou mentalmente trabalhando o que você passou no workshop e o que vocês postaram aqui
eu entendi o ponto, mas o que realmente eu não estou enxergando é como aplicar esse desenvolvimento em camadas (de verdade) ao uma aplicação web de verdade
mas como você mesmo disse, tem horas que nem compensa desenvolver em camadas
mesmo assim, eu quero muito entender como aplicar o desenvolvimentos em camadas ao desenvolvimento web
eu sei que vão me indicar um grosso livro do martin folwer (como escreve mesmo), GOF, etc, mas tem alguma aplicação (web-based) com os fontes abertos por aí que realmente esta todinha desenvolvida em camadas com todas essas boas práticas?
É muito mais fácil você dar uma lidinha no livrinho do Fowler (é, livrinho, livrão é o Pro Spring que tem 806 páginas) e depois pegar uma aplicação escrita em camadas pra dar uma estudada. Se você pegar antes, é mais provável que você não perceba muita coisa.
Estudar não mata :mrgreen:
Por que a galera de informática não gosta de ler heim?
Outra coisa, se você quer uma boa aplicação de exemplo, baixa o JForum, é 10 e não tem nenhum framework esquisito.
Já leu esse, Maurício? Eu comrepi no CJ. Legal que no domingo os caras colocaram no lugar onde ele estava outro de Spring, devem ter pensado: “aquele carioca otario vai gastar mais duzentas pratas agora”
Mas na real nem comrpei proque eh da wrox, e livro da wrox com mais de um autor nao presta, e tenho dito.
Microfilo, se eu conseguir colocar o codigod e exemplo online hoje aidna, voce pode baixar la. Na verdade, eu quero colcoar o conteudo do minicurso num pdf.
Homi, coloca esse negócio no ar logo! Vocês gravaram áudio ou vídeo lá?
Eu gostei Phillip, fala de quase tudo. Conceitos básicos de IoC e IoC no Spring, AOP, suporte a bancos de dados (JDBC, Hibernate e iBatis), controle de transações (com e sem JTA), remoting e suporte a EJBs, agendamento com Quartz e Timer, MVC (do Spring) e integração do o Struts. Na parte do Spring MVC também fala de como usar ele com JSPs, Velocity, FreeMarker e XSLT. No fim fala um pouco sobre o RCP do Spring, mas o projeto anda meio parado.
Faltou falar sobre o Acegi, integração com JSF, a versão do Hibernate é 2 (as mudanças pra 3 são apenas os pacotes, mas mesmo assim né…), também não falou sobre integração com SiteMesh (tem no livro do Raible, mas me disseram que ele não é muito bom não…) e o WebFlow (nenhum livro abordou o WebFlow ainda).
Você comprou por duzentas pilas velho? Ave maria! :shock:
Eu comprei pela amazon e saiu uns 100 reais.
O da Wrox eu achei interessante, porque tem o Rod Johnson e o Juergen Hoeller, mas livro com muitos autores é complicado mesmo. Parece que ele nunca segue um caminho reto e os caras não costumam referenciar o resto do livro :lol:
o Spring in action fala um pouco do acegi, nao sei se suficiente porque aidna nao usei.
160 
O to terminando o “without EJB”, mas quandoa cabar acho que vou ler algo mais light, gerencia agil ou cosia do tipo. Tenho que vencer a tentação de só ler livros altamente técnicos o tempo todo
Ataulmente tem Managing Agile Projects, Peopleware e Surviving Object-oriented Projects na fila.
Eu to terminando o PoEAA e to indo (provavelmente) pro “without EJB”.
To pensando em pegar mais algumas coisas sobre desenvolvimento ágil (li o novo XP explained em duas noites, o livro é d+), mas num sei pra onde ir. Alguma dica?
basicamente de Design, ams um foco ágil muito enormemente grande: http://www.objectmentor.com/resources/bookstore/books/AgileSoftwareDevelopmentPPP
vamos lá…
fazendo uma aplicação aqui usando o mentawai, pensei em como colocar persistência em camadas…
deêm uma olhada, me digam o que vocês pensam
public class Noticia {
private String titulo;
private String corpo;
private Date dataPublicacao;
private boolean estaPublicada;
private GerenciadorDePersistencia gerenciadorDePersistencia;
// getters e setters
public static List list(){
return gerenciadorDePersistencia.list(Noticia.class);
}
public void publicar() {
if (!estaPublicada) {
this.estaPublicada = true;
gerenciadorDePersistencia.update(this);
}
}
// entre outros
}
O gerenciador de persistencia seria um tipo de DAO, no caso um DAO gerenérico para o hibernate.
eu chamaria o método publicar\listar\cadastrar\etc em uma action e criaria o gerenciador de persistência no construtor ou injetaria com IoC…
esse esquema seria o esquema ideal para persistência?
Você vai guardar em um flag se a notícia está publicada ou não?
Cadê o identificador dela?
O Active Record é mais ou menos assim mesmo.
Você vai guardar em um flag se a notícia está publicada ou não?Cadê o identificador dela?
O Active Record é mais ou menos assim mesmo.
esqueci do Id…
eu preciso guardar o flag sim, o esquema vai ser parecido com o do php-nuke, o cara manda a notícia e os admins aprovam ou apagam ela, por isso preciso da flag…
o que falta para ser um Active Record?
eu preciso guardar o flag sim, o esquema vai ser parecido com o do php-nuke, o cara manda a notícia e os admins aprovam ou apagam ela, por isso preciso da flag…
E onde é que ela fica antes de ser publicada? Se esse “publicar” for o método “save” de AR, enquanto ela não for publicada ela vai ficar na memória?
Os “entre outros”.
Já que você quer mesmo trabalhar com AR, defina uma interface comum, com os métodos CRUD, que todos vão implementar, melhor do que cada um chamar o método de um jeito diferente. Botar o getId e o setId nela também é uma boa.
essa conversa me deu sede
pronto
eu bebi a água.
e estava bem geladinha.