Olha aqui um tutorial lega de Patterns…
Aqui está falando do Memento… super prático!
http://www.lia.ufc.br/~eti/menu/modulos/Pattern/aulaDesignPatternsII4pp.pdf
Medod e vc pensar num memento baseado em XML :lol: brincadeira, é tendo idéias ridículas que se aprende, que diga eu com o Cereal.
vamos lá, jprogrammer, vou tentar falar de Eiffel, que eu nucna usei a sério mas conheci no livro do Meyer.
Em eiffel, toda vez que você delcara uma feature (método ou atributo, nas linguagens mais puristas eles são meio indistinguíveis até certo ponto), você precisa declarar qual classe vai ter acesso á isso. Chegao ao ponto que se você quer usar o método da classe com uma chamada qualificada (“this.doStuff()” em vez de “doStuff()”) você precisa exportar para si mesmo!
trazendo para a OO disponível e desenhando um pseudo código Java aqui, teríamos:
class Usuario{
private String login, senha;
public Usuario(String login){this.login = login;}
public String getLogin(){return login;}
public void setSenha(String senha){this.senha=senha;}
public boolean compararSenha(String outra){return senha.equals(outra);}
exported [shoes.data.Dao] String getSenha(){return senha;}
}Uma sintaxe meio tosca, porque seria melhor se pudéssemos definir os modificadores de acesso para grupos de features (como em C++), porque selective export não foi feito para trabalhar com modificaroes private/public (para marcar algo como public, poderíamos exportá-lo para java.lang.Object) e porque eu não sou ´nenhum mestre em lingaugens de programação :P.
Bom, nesse caso, as classes clientes geralmente veriam essa API:
class Usuario{
public String getLogin()
public void setSenha(String senha)
public boolean compararSenha(String outra)
}Enquanto as classes descendentes de Dao veriam:
class Usuario{
public Usuario(String login)
public String getLogin()
public void setSenha(String senha)
public boolean compararSenha(String outra)
String getSenha()
}Note que em C++ você pdoe declrar classes que acessem seus métodos privados, não pode exportar diferentes APIs para diferentes classes de objetos.
Eu já usei Memento apr apersistir e não foi uma experiência muito legal. Funciona quandov coê tem poucos objetos persistidos, mas com uma quantidade muito grande vira uma bagunça dos infernos.
Entretanto, faz algum tempo que eu tenho essa idéia de como ele poderia ajudar na persistência…
Pelo que entendi do Memento, o objetivo dele é recuperar o estado de um objeto!
Por exemplo…
:arrow: Vc cria um objeto
:arrow: edita seu objeto!
:arrow: Salva o seu objeto em um lugar temporario, armazenando o memento deste objeto em um repositório
:arrow: continua brincando com seu objeto…
:arrow: vc faz uma cagada sem querem em seu objeto
:arrow: vc busca o memento no repositório e consegue desfazer a cagada que vc fez!
Bom… agora estou com dúvida no que eu deveria usar o Memento?
Eu deveria usar o Memento como uma opção para aquela gambiarra que eu chamei de XmlDTOGenerator?
Philip, qual é o ponto em que eu disse alguma coisa que fez com que vc me indicasse este padrão! eu realmente não o conhecia e agora já tenho uma idéia básica sobre ele. Valeu…!!! Mas não consigo captar onde é que está a falha… onde eu poderia melhorar usando o padrão memento…
Só me dê uma idéia de onde está o problema, que aí eu tento me virar!
Valeu!
Thiago Senna
O que você precisa persistir não é o objeto em si, é o estado do objeto, com memento você extrai esse estado e pode armazená-lo, depois “preencher” uma instância com esse estado. 
Mas esse selective export não existe em java ?
Que pena !
E um negócio assim ficaria legal ?
package funcionario;
class Funcionario
{
int id;
String nome;
public void setNome(String nome)
{
this.nome = nome;
}
public void cadastrar()
{
id = geraId();
FuncionarioDAO dao = DAOFactory.getFuncionarioDAO()
dao.salvar(this);
}
}
public abstract class FuncionarioDAO
{
protected int id;
protected String nome;
protected void salvar(Funcionario f)
{
id = f.id;
nome = f.nome;
}
}
package data.jdbc;
public class FuncionarioJDBCDAO extends FuncionarioDAO
{
protected void salvar(Funcionario f)
{
super.salvar(f);
sql = "insert into funcionario values ('" + id + "','" + nome + "');
}
}
package data.hibernate;
public class FuncionarioHibernateDAO extends FuncionarioDAO
{
protected void salvar(Funcionario f)
{
// nao precisa fazer nada pois hibernate é esperto
session.save(f);
}
}
Funcionario f = new Funcionario();
f.setNome("Maria")
f.cadastrar();humm… entendi…
Ou seja… ao invés daquela idéia se chamar XmlDTOGenerator ele poderia se chamar XmlMementoGenerator…???
Aproveitando a idéia do XmlDTOGenerator, o memento seria criado automaticamente. Um framework seria capaz de pegar o objeto de negocio e criar automaticamente um memento dele, ou seja, uma representação do seu estado.
Desta forma vc não precisaria se preocupar em implementar os métodos getMemento e createMemento dentro da classe de negócio!!!
Aluno aluno = new Aluno();
// seta dados do aluno
AlunoDAO dao = new AlunoDAO();
dao.create(XmlMementoGenerator.createMemento(aluno));
É isso mesmo?
Se a iidéia é mesmo boa, podemos ir conversando e tentar fazer este troço amadurecer!
Abraços!
Thiago
Bom… parece que XmlMementoGenerator não parece ser muito do agrado da galera… Alguma coisa errado com o XML? Seria isso? Não vale a pena transportar dados de um objeto através de um arquivo xml?
Xml seria custoso para transportar dados até mesmo em uma aplicação local, que não seja distribuída?
que tal:[code]
MementoGenerator.getXmlMemento(aluno);
MementoGenerator.getPropertiesMemento(aluno);
MementoGenerator.getGenericObjectMemento(aluno); //viagem
MementoGenerator.getUmaIdeiaMelhorMemento(aluno);
[/code]
[quote=Thiago Senna]
Ou seja… ao invés daquela idéia se chamar XmlDTOGenerator ele poderia se chamar XmlMementoGenerator…???[/quote]
Eu sabia que ia me arrepender… :lol:
Não, esqueça XML, para que você precisaria dele?
Mas tem um problema com permitir que classes herdadas vejam os atributo é ter uma código malicioso para burlar a segurança.
ex:
// continuando o código acima...
Funcionario f = new Funcionario();
FuncionarioDAO daoSacana = new FuncionarioDAO()
{
public void salvar(Funcionario f)
{
id = 1234;
super.salvar(f);
}
}
daoSacana.salvar(f);
f.cadastrar();
Por isso é interessante permitir apenas um sub-classe que herda o próprio objeto de dominio fazer a persistencia, pois não irá existir o perigo de fazer besteira.
Mesmo que alguem crie uma subclasse a partir dele não será do objeto funcional
ex:
Funcionario f = getFuncionario()// factory
f.cadastrar();
esse é o objeto funcional.
Funcionario fSacana = new Funcionario()
{
public void cadastrar()
{
super.cadastrar();
// nao faz nada pois não é a implementação
}
}
[quote=pcalcado][quote=Thiago Senna]
Ou seja… ao invés daquela idéia se chamar XmlDTOGenerator ele poderia se chamar XmlMementoGenerator…???[/quote]
Eu sabia que ia me arrepender… :lol:
Não, esqueça XML, para que você precisaria dele?[/quote]
Era exatamente isso que eu queri ouvir!!!
Pq XML não é uma boa opção?
Tem alguma opção mais interessante para se armazenar o estado de um objeto, considerando a idéia de criar um mecanismo capaz de gerar o memento automaticamente?
Que segurança, cara-pálida?
Acho que o cv já mostoru o quão seguro é uma classe Java…
Modificadores de acesso são para encapsulamento e information hiding, use as milhões de configurações de JVM e J2EE para segurança
Pica um HashMap maluco !!!
Seguraça que eu falo é os contraints da classe.
Seria o encapsulamento e o data hiding.
[quote=jprogrammer]Pica um HashMap maluco !!!
[/quote]
boa…
[quote]Aluno aluno = new Aluno();
// seta dados do aluno
AlunoDAO dao = new AlunoDAO();
dao.create(HashMapMementoGenerator.createMemento(aluno));
[/quote]
Ae THiago, que eu saiba o Memento (li por alto) é isso que tu falou, e serve para voltar o estado de um objeto, para faze CTRL+Z. Não entendi o que tem a ver com o assunto que vocês estão discutindo, que aliás tá uma macarronada legal.
Uhm…acho que entendi o qeu você quis dizer, mas esse negócio de subclasses para serviços como eprsistência é ruim. Que tal aspectos?
Quando eu desligar o computador e ligar de novo, o que eu preciso fazer com os estados dos meus objetos persistidos?
Shoes
Fale mais sobre esse negocio de aspectos !
renato3110 cara se vc não tá entendendo o tópico saia fora.
O negocio tá ficando alto nível…
Putz, melhor ouvir merda que ser surdo, quer dizer, melhor ler merda que ser cego.