Classe para Unidade e Classe para coletividade

NMO parece-me melhor que os métodos façam parte de uma outra classse que possui funcionários mas com sua identidade própria, mais ou menos mudar o nome da classe, tipo Empresa, que possui funcionarios, e tipo:

Depois daquele tópico sobre classes de dados (que aliás o último post o Shoes não respondeu ), eu fico pensando em colocar lógicas de coleção como métodos estáticos da classe Funcionario:

Mas não sei se seria cooool…

Link, please?

Já pensei nisso, colocar lógica de coleção como método estático.
O problema é com a herança.

Legal a ideia da indentidade própria, mas o problema é que eu posso ter muitos métodos na classe Empresa.

Link: Classes de dados e classes de lógica

Jprog., qual o problema de muitos métodos?

Estava pensando na seguinte arquitetura.
Gostaria de críticas e sugestões.

// definição
package business;

public interface Venda
{
  public void efetuar();
}

public interface Estoque
{
  public void processarBaixa(int codigoProduto, int qtd);
}

public abstract class BusinessFactory
{
   public static final obterInstancia() {
      return new JDBCBusinessFactory();
   }

   public abstract Venda obterVenda();
   public abstract Estoque obterEstoque();
}


// implementação
package businessImp;

public abstract class VendaImp implements Venda
{
  protected abstract void implementarProcessoVenda();

  public void efetuar()
  {
    // regra de negocio   
    implementarProcessoVenda(); 
    BusinessFactory b = BusinessFactory.obterInstancia(); 
    Estoque e = b.obterEstoque();
    e.processarBaixa(1,2);
  }   
}

public abstract class EstoqueImp implements Estoque
{
  protected abstract void implementarProcessoBaixa(int codigoProduto, int qtd);

  public void processarBaixa(int codigoProduto, int qtd)
  {
    // regra de negocio   
    implementarProcessoBaixa(codigoProduto,qtd);
  }   
}

package jdbc;

public class JDBCBusinessFactory extends BusinessFactory
{
   public Venda obterVenda()
   {
      return new VendaJDBC(getConnection()):
   }

   public Estoque obterEstoque()
   {
      return new EstoqueJDBC(getConnection()):
   }
}

class VendaJDBC extends VendaImp
{
  VendaJDBC(Connection conn)
  {

  }
  
  protected void implementarProcessoVenda()
  {
     insert into venda ...
  }
}

class EstoqueJDBC extends EstoqueImp
{
  EstoqueJDBC(Connection conn)
  {
     
  }

  protected void implementarProcessoBaixa(int codigoProduto, int qtd)
  {
     update estoque set qtd = qtd ...
  }
}

BusinessFactory b = BusinessFactory.obterInstancia(); 
Venda v = b.obterVenda();
v.efetuar();

Baseado em algumas conclusões minhas baseadas nos foruns estava pensando em tirar os DAOs fora.
Por que se pensarmos, o termo classe de persistencia é estranho.
Pois o que existe são operações e implementações de operações.

ex:
o processo de efetuar uma venda tem como ação gravar na tabela do banco.
Mas se o processo fosse gravar no mainframe, ou etc, ou emitir uma mensagem.
Fiquem a vontade !

Me parece que você está falando do caso onde a aplicação é só tira e bota no banco, acho que chamam isso de CRUD.

Eu queria fazer ou achar um framework (agh) que você conseguisse criar aplicações assim só fazendo configurações, sem nenhum código :mrgreen: Ia ser massa!

E não gostei disso heheheheheh feio! :evil:

Não so to falando de CRUD não.
Esse exemplo de JDBC é apenas uma ilustração.
Pode ta esquisito mesmo, mas tem bastante fundamento.

Observe bem. estou separando implementação tecnológica (persistencia) de lógica de negócios , não tem nada de CRUD aí.

EDITADO
O grande problema é usar o OO com os DAOs expondo atributos desnecessários.

Agora se a própria classe se “persiste”.
Porque pesisteir é estranho. O que existe é a operação
cadastrar, registrar,etc.

Gostaria de sugestões…

Eu acho que utilizar DAO´s tem mais uma significância tecnológica, que diz respeito a tecnologia que se usa e como se usa.
Por exemplo se você vai ter uma forma de pesistência imutável, não vejo problemas em retirar o DAO e delegar a responsabilidade para o próprio objeto do domínio.

É verdade Rafael.
Se vc tem uma forma de persistencia única delega-la para os objetos de domínio é bem mais fácil.

O grande desafio é quando vc tem formas de persistencias mutáveis.

É nessas horas que eu vejo a diferença entre a teoria e prática.
Falar de domain model, OO , sei lá o que é muito bonito.
O problema é quando temos obstáculos tecnólogicos.

Gostaria de mais sugestões… (de preferencia com argumentos concretos e de quem realmente entendeu a proposta do tópico)

Qual eh o grande desafio? Nao deixe a gente salivando de expectativa desse jeito! :mrgreen:

Meu, to meio que viajando quanto à este assunto de vocês!

Quando estou fazendo meu modelo de negócio, eu mando tudo quanto é assunto referente a persistência para a casa do caralh…!!! :shock: :shock:

É… é isso mesmo!

Eu me limito em criar um modelo de negócios independente da persistência. Daí, eu crio os daos de forma que eles sejam capazes nada mais nada menos de recuperar ou salvar no banco de dados os dados que estão dentro da camada de negócio. Ou popular meu modelo só com os dados que me interessam!

Na faculdade aprendi a criar o modelo junto com as classes de persitência. Agora na prática, simplemente eliminei a persistência do modelo de negócio completamente! Fica muito mais fácil modelar o sistema. É muito prazeroso saber que seu modelo resolve o problema. e que no fim de tudo, o dao ou qualquer outra coisa que persiste só esta lá para recuperar pra mim dados de um iteração que aconteceu outro dia!

Confesso que é muito bonito o modelo contendo os métodos salvar, update, create e delete. Então optem por criar uma interface com as operações básicas, crie um DAO que implemente esta interface, e coloque ela na sua classe de negócio usando IOC… ou algum pattern de criação de objetos!

Crie no seu modelo os métodos save, delete e companhia delegando a tarefa para o dao!

Abraços!
Thiago

Ué, caso for mutável, então utilize os DAO. Seu domínio continuará tal como está, porém os objetos aos invés de chamar a ‘engine’(caraleo, não me veio palavra melhor pra dizer isso) de persistência diretamente, delegariam a responsabilidade para os DAO´s.
Só não sei dizer se os DAOs fariam parte do teu domínio ou não, ajuda dos universitários.

jprogrammer:

Gostaria de mais sugestões… (de preferencia com argumentos concretos e de quem realmente entendeu a proposta do tópico)

É isso que eu quero saber também !
Como delegar o mecanismo de persistencia para os objetos de dominio e ainda ter várias maneiras de fazer isso ?

class Funcionario
{
   private int atributoQueNaoPodeSerVisto;

   public void cadastrar()
   {
      //  pode ser JBDC, hibernate, XML, mainframe, etc.
   }
}

Como poderiamos implementar isso da maneira menos… TOSCA.
EDITADO:
Como o Thiago falou a modelagem inicial não teria qualquer mecanismo de persistencia. Para isso achei legal usar a ideia do shoes, usando interfaces com os métodos de negócio.

A implementação de como isso vai ser feito aí é outra historia.
Também acho que os métodos como salvar, excluir não devem fazer parte dos métodos de negócio somente como implementação.

jprogrammer:

É isso que eu quero saber também !
Como delegar o mecanismo de persistencia para os objetos de dominio e ainda ter várias maneiras de fazer isso ?

class Funcionario
{
   private int atributoQueNaoPodeSerVisto;

   public void cadastrar()
   {
      //  pode ser JBDC, hibernate, XML, mainframe, etc.
   }
}

Como poderiamos implementar isso da maneira menos… TOSCA.

hahaha!!! Abstract Factory!! Ou Factory Method???

É um desses dois, ou os dois juntos!!!

IMHO:
[url]http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html[/url]

class Funcionario
 {
    private int atributoQueNaoPodeSerVisto;
 
    public void cadastrar()
    {
      FuncionarioDAO.cadastrar(funcionario);
    }
 }

class FuncionarioDAO{
   void cadastrar(Funcionario){
      stmt.executeUpdate("INSERT INTO...") ;//JDBC
      funcionario.save();//Hibernate
      ...
}

JProgrammer…

Imagine que vc configurou qual é o banco ou mecanismo de persistência em um properties, certo.

Sua abstract factory ia ser este propertie e definir qual é o mecanismo de persistência que está sendo utilizado!

quando seu modelo chamasse o método cadastrar,

class Aluno {

public void cadastrar() {

    AlunoDAO = DAOFActory().getAlunoDAO();

}

Mais ou menos isso:

Assim, vc pode usar o mecanismo de persistência que vc quiser… deve ter algumas limitações… mas em geral, dá sim…
Acredito que se usar JTa para as transações fica ainda mais tranquilo!

(obs: não conheço JTA!!) Se eu tiver falado merda, tenham compaixão de mim!

Thiago

Mas foi isso que eu coloquei aí em cima:

1 - interface com definicção dos métodos de negócio.
2 - Classe abstrata com implementação dos métodos de negocio
3 - Classe concreta com implementação dos processos de persistencia.

O item 2-3 que é foda !

Como fazer isso sem misturar lógica de negócio e dados.

o DAO é maravilhoso, o problema é expor atributos desnecessários para o DAO.

class Funcionario
{
  private int atributoQueNaoPodeSerVisto;

   public void cadastrar()
  {
      FuncionarioDao.salvar(this);
  }
}

class FuncionarioDAO
{
   public void salvar(Funcionario f)
   {
      f.atributoQueNaoPodeSerVisto // opa;
   }
}

OBS:
Já sei que o hibernate pode fazer isso.
O problema é com outro tipo de persistencia.

É… CGLIB talvez resolva seu problema… ué???

Ou quem sabe, Reflection!

Ou… hummm é gambiarra… mas… crie uma … interfac…e (ai…) para… o… funcionario… e passe ele para …o…oo…o…o DAO!!! Nossa… dá até medo falar isso!

Ou use hibernate!

Não to falando que é foda.
É por isso que vou usar ainda por muito tempo os POJOs burros e passa-los daqui-pra-la e de lá pra cá arregabhando tudo que tem dentro deles para todo mundo saber inclusive os DAOs

OBS:
Em um projeto não me aventuraria hoje em fazer isso.
Apenas é uma discussão filosófica…

:lol: hehe!! Isso é meio folosófico mesmo!

Mas por que vc se preocupa em passar dados desnecessários para o dao? Se o DAO vai persistir, ele vai persistir apenas o que interessa!

A não ser que vc tenha algum tipo de DAOTraira!??? :shock: :shock:

Abraços!
Até Amahã… fui

Foi a parte dos atributos desnecessários que não entendi.

Se você tem uma ‘engine’(ainda não encontrei) de persistência imutável, você não precisará obrigatoriamente dos DAOs.

Se ela é mutável, qual o problema do DAO conhecer a implementação do objeto que ele deve persistir? Se ele é responsável pela persistência de determinado objeto, ele tem um tipo de contrato com o objeto, não vejo o por que de não conhecer sua implementação. Afinal, quem utilizará o DAO é somente o objeto(Funcionario>FuncionarioDAO), e não um outro objeto qualquer do domínio.

Estou sendo apenas puritano.
Se fomos implementar o OO realmente devemos expor somente os atributos que necessários que fazem parte do modelo de negócios.

ex:

class Funcionario
{
  // existe por necessidade da persistencia NO CASO;
  private int id; 
  public void setId(int id) {}
  public int getId() {}

  // metódos e atributos de negocio, importa para o modelo
   private String nome;
   public void setNome(String nome) {}
   public String getNome() {}
   public void salvar()
  {
     
  }
}

O id no caso é um atributo que não faz parte do modelo de negócio esta aí apenas por necessidade da persistencia;
Se ele fizesse parte do modelo não teria problema.

A questão é que o DAO provalmente ficará em outro pacote o que faz com que todos os atributos da classe Funcionario que serão persistidos pelo DAO precisarão ser public;

Nao necessariamente. Atraves de reflection (e permissoes de seguranca apropriadas) voce consegue ler atributos privados de praticamente qualquer classe.

Pergunta: pq vc nao le mais sobre o Hibernate? Ele faz tudo isso que vc quer fazer, sem enchecao de saco, sem mutilar os seus objetos, sem frescura, e tem um moooooonte de outros projetos rodando com ele em producao pra provar que a coisa funciona. Pq nao?

Cv pode ser uma alternativa o reflection.

Referente ao hibernate eu tenho a plena noção de que é a mehlor solução de persistencia hoje.
O topico aqui é apenas para a discussão de uma arquitetura gernérica, ou seja, um discussão puramente “filosófica”.

É difícil eu sei, mas se algume falasse para vc como já falarm para mim:

• Nosso sistema roda em CACHÉ ou MUMPHS ?
• Ai vc fala não.
• Ai vem a resposta:
• Então mude para que ele funcione…

É por isso que eu fico enchendo o saco do pessoal, para estra preparado para casos como esses…

Nao “pode ser”. É! :mrgreen:

jprogrammer:

Referente ao hibernate eu tenho a plena noção de que é a mehlor solução de persistencia hoje.
O topico aqui é apenas para a discussão de uma arquitetura gernérica, ou seja, um discussão puramente “filosófica”.

Entao pra que discutir e filosofar em cima de um problema resolvido?

jprogrammer:

É difícil eu sei, mas se algume falasse para vc como já falarm para mim:

• Nosso sistema roda em CACHÉ ou MUMPHS ?

Fim de papo.

jprogrammer:

É difícil eu sei, mas se algume falasse para vc como já falarm para mim:

• Nosso sistema roda em CACHÉ ou MUMPHS ?
• Ai vc fala não.
• Ai vem a resposta:
• Então mude para que ele funcione…
  

Se a ‘engine’(ah, desisti) de persistência foi definida como imutável, sacrifique quem definiu isso.
Se não foi, basta só mudar o datasource ou os parâmetros da classe de conexão.

Mas o que mudar o banco tem ha ver com o atributo privado lá de cima?

O problema do atributo privado é a frescura OO.
E tem fundamento.
Esse atributo id só existe para a persistencia não para o modelo no caso.
Se eu quiser deixar a aplicação o mais OO possivel tenho que esconder esse atributo.

Mas como é dificil ter uma aplicaçao 100% OO vamos deixar.
É dificil coincidir uma modelagem OO com as limitações tecnoloógicas como persistencia que não faz parte do modelo de negócio.

Como foi abordado em outro tópico temos que adaptar nossas classes para a persistencia.

EDITADO:
No caso existem formas de persistencia não relacional.
Ter DAOs que persistem nessas formas é importante se quisermos ter uma arquitetura generica.

O dilema está entre EXPOR OS DADOS DA CLASSE DE DOMINIO PARA ESSES DAOS PODERAM ACESSÁ-LOS

@heditadu

Esse seu pensamento é semelhante a uma parada que tenho refletido ultimamente. Tipo, você tem os seus objetos de negócio (domínio sei lá), que é independente de qualquer coisa, não conhece anotações, persistência, serialização XML, enfim, são independentes. No entanto, são inúteis na prática. Ou seja, você cria seu domínio (não sei se tô usando o termo certo), mas precisa torná-lo em algo palpável, em algo real, utilizável. Ou seja você traz os seus objetos do contexto abstrato pro contexto concreto, adicionando-lhes aspectos tecnológicos. Tipo vira EJB, vira Servlet (hein?), possui persistência Hibernate, depois JDBC etc, é capaz de interagir agora com Frameworkmela Talz, e tem XML no meio, e etc etc etc.

Tá mas qual é o problema? Parece-me que as pessoas se decepcionam quando embutem persistência, XML, Excel, PowerRangers etc nos objetos de negócio quando descobrem que os colocou numa cova, atrofiados de tecnologias. E se decepcionam quando tentam separar isso, quando os objetos passam a ser mais puros, mas menos inteligentes e cria-se outras classes externas para ajudar os coitados, ficando uma coisa espalhada e menos fácil de usar. Tipo um dilema.

Solução? Poder clicar no objeto com o mouse, escolher Add/Remove Aspect e escolher da lista: PersistenceAspect, SendMailASpect, RMIASpect, XMLAspect, JNIASpect, e por aí vai.

Problema dessa solução? Ela não existe.

Tá meio ou total embolado mas para os guerreiros que porventura consigam entender “meus sentimentos” (alguém??), é isso.

PS: acho que essa foi a viagem na maionese OO mais doida que ja fiz.

jprogrammer:

No caso existem formas de persistencia não relacional.
Ter DAOs que persistem nessas formas é importante se quisermos ter uma arquitetura generica.

Me da um exemplo de um projeto em que voce esteve e, do nada, chegaram pra voce dizendo que nao iam mais usar bancos de dados, e que de agora em diante toda a persistencia de objetos seria feita atraves de palitinhos de dente cuidadosamente dispostos em forma binaria pela tia do café?

Uma arquitetura generica como essa que voce propoe (e, pelo visto, nunca pos a mao na massa pra fazer uma, ou voce saberia que se fosse tao facil ja teriam feito) nao funciona e nunca vai existir pq cada meanismo de persistencia tem peculiaridades diferentes, e objetos vivos na memoria simplesmente nao sao a mesma coisa quando transformados em uma serie de bytes, por mais macumba que voce faca.

Isso nao eh um dilema. Eu ja mostrei nessa mesma thread que isso eh perfeitamente possivel e facil de fazer usando reflection. Voce nao le os meus posts, ou nao entendeu o que eu disse?

O cv o negócio do reflection eu gostei e é a solução.
Apenas estava explicando para o Rafael Nunes o porquê da discussão com o atributo privado.

Mas estava pensando em uma coisa…
E colocar atributos no DAO.
Podem falar se fica tosco.

class Funcionario  {
    private String id;
    private String nome;

    public void setNome(String nome) {
       this.nome = nome;
    }

    public void cadastrar()  {
       FuncionarioDAO funcionarioDAO = getFuncionarioDAO(); // factory
       funcionarioDAO.setId(geraId());
       funcionarioDAO.setNome(nome);
       funcionarioDAO.salvar();
      }
}

class FuncionarioDAO {
    private String id;
    private String nome;

    public void setId(int id) {
       this.id = id;
    }
   
    public void setNome(String nome) {
       this.nome = nome;
    }

   public void salvar() {
      session.save(this);
   }

}

Funcionario f = new Funcionario();
f.setNome("Maria");
f.cadastrar();

Estranho esse papo de “arquitetura generica”. A minha opiniao sobre isso eh algo que tenta solucionar os problemas do mundo e acaba sempre detonando 200 bombas atomicas.

Se ficar discutindo a “filosofia” apenas, onde isso tudo ira chegar? talvez em 10 paginas de mensagens e nenhuma coisa nova agregada.

Vai chegar num ponto - e nao precisa de muito esforco para isso - onde abstrair algo vai ser estupidamente dificil, e voce acabara fazendo horrores de codigo para conseguir deixar “generico”, e, em razao disso, voce tera complexidade / bugs em demasia

Rafael

jprogrammer:

Mas estava pensando em uma coisa…
E colocar atributos no DAO.
Podem falar se fica tosco.

HHmm… voce fez o DAO ser uma copia da entidade simplesmente para “evitar” uma possibilidade remotissima de algum codigo “malicioso” tentar acessar atributos via reflection? Nao me parece uma boa coisa.

Se voce quer tanto evitar passar um Funcionario ao save() do DAO, entao faca pelo menos o save() receber todos os parametros (save(nome, endereco, salario) ). Mas, de qq maneira, voce esta sacrificando legibilidade e facilidade de manutencao por uma hipotese que muito provavelmente nao ira afetar de maneira relevante o seu sistema.

Rafael

Na prática mesmo isso é perda de tempo.
Concordo com vc Rafael.

Apenas gostaria de discutir…
Eu acho que agrega sim.

Mas pensando bem até que não ficou ruim…
Não vejo empecilho na manutenção desta maneira.
O estranho é o nome de DAO, mas que não deixa de ser DAO.
Sei lá outro nome…
O estranho é mapear o DAO no hibernate. :lol:

jprogrammer:

Na prática mesmo isso é perda de tempo.
Concordo com vc Rafael.

Apenas gostaria de discutir…
Eu acho que agrega sim.

Agrega ate certo ponto. Porem, bater o pe por causa de ter que ter um id ou nao, “simplesmente por causa da persistencia”, eh meio que chover no molhado.

Discutir a implementacao agrega bastante.

Rafael

jprogrammer:

M
O estranho é o nome de DAO, mas que não deixa de ser DAO.
Sei lá outro nome…

VO? DTO?

Rafael

O pessoal chato deixa o cara bostejar, é ótimo fazer isso.

E jprogrammer, quanto a solução, eu curti o que o Shoes sugeriu em outro tópico, com interfaces internas. Jájá posto algum código.

JProgrammer!

Você pensou na possibilidade de seu objeto de domínio gerar um arquivo xml, e passar esse documento xml para o DAO!

O DAO por sua vez conheceria apenas os dados que estão no arquivo xml, e nada mais! Ele não será capaz de interagir com seu objeto de negócio de maneira alguma, garantindo desta maneira a proteção e segurança que você tanto deseja!

Isso não é lá grande coisa. Nada mais é que um DAO, mas ao invés de passar um objeto como DTO, ele passaria um Arquivo XML!

Agora se prepare:

Abraços!
Thiago Senna

Parabéns Thiago! Você acabou de criar algo parecido com um DTO, só que muito, muito pior!!! :XD:

E qual a diferença do DAO receber um XML ou um objeto com atributos?

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAAHAHAHA… arf arf…HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAHAHAHAHAHAHAHAHA!!!

Entre gerar XML e passar um DTO é melhor a segunda opção que usa menos processamento.

Outra solução seria colocar os DAOs no mesmo pacote dos Domain models.

public class Funcionario {
    public void cadastrar() {
       FuncionarioDAO f = FuncionarioDAO.obterInstancia();
       f.salvar(this);
    }
}

abstract FuncionarioDAO{

    public static FuncionarioDAO obterInstancia() {
        return new FuncionarioHibernateDAO();
        //pode ser via parametro;
    } 

    public abstract void salvar(Funcionario funcionario);
}   


class FuncionarioHibernateDAO extends FuncionarioDAO
{
    public void salvar(Funcionario funcionario)
    {
        session.save(funcionario);
    }
}

class FuncionarioCacheDAO extends FuncionarioDAO
{
    public void salvar(Funcionario funcionario)
    {
        xyz.save(funcionario.codigo,funcionario.nome);
    }
}

A parte boa disso é que somente(±) o objeto de dominio consegue
ses persistir evitando que outra classe chame o DAO.

jprogrammer:

Entre gerar XML e passar um DTO é melhor a segunda opção que usa menos processamento.

Outra solução seria colocar os DAOs no mesmo pacote dos Domain models.

A parte boa disso é que somente(±) o objeto de dominio consegue
ses persistir evitando que outra classe chame o DAO.

3- Solução … USAR HIBERNATE E PARAR DE BATER CABEÇA :twisted:

Parece a menos pior até agora.

package lipe.person

public interface Person
public class PersonImpl
protected class PersonDAO
protected class PersonView

Realmente… a minha idéia for surpreendente!!!

Bom… eu reinventei o DTO, né… :oops:

Quando eu for para o SunTechDays em 2006 eu vou subir no palco e contar pra todo mundo esta idéia brilhando! Daí quem sabe eu consigo ganhar a jaqueta do JAVA!!!

Bom… eu sei que aquela idéia horrível era um DTO. Por isso sugeri que fosse um framework que automatizasse a criação do DTO, para que o desenvolvedor não tivesse aquele trabalho horrível de criar e popular o DTO na mão!

Achei que se isso fosse gerado automaticamente por um framework, talvez valesse a penas, e não adicionaria tanta complexidade no código!

Exemplo:

public void dtoGeneratorExample() {

   Aluno aluno = new Aluno("Thiago", 22);
   AlunoDAO dao = new AlunoDAO();

   dao.save(XmlDTOGenerator.getXmlData(aluno));

}

Tá ai!!

Mas por favor! Se isso for ridículo, critiquem e me dêem um puxão de orelha!

Afinal, se eu tiver um mecanismo que gerasse o TO automáticamente não seria algo interessante. Ou ainda sim utilizar DTO em sua aplicação seria de certa forma uma comédia???

Abraços!
Thiago Senna

Cara a gente já sabe do hibernate.
Será que vou ter que repetir mil vezes:
NA PRÁTICA NÃO TEM OUTRA COISA: HIBERNATE

Apenas estamos exercitando nossas mentes.
Esqueça nesse tópico que existe hibernate. Isso aqui é conceito.

Enquanto a ideia do LIPe realmente é mais ± isso que eu pensei.
Posta o código…

Jaqueta do Java, nao, mas um convite pro American Idol ou Show de Calouros, talvez

Sim, eh ridiculo. Toma um puxa de orelha.

Serializar dados em XML pra transferir de uma classe pra outra so pq vc nao sabe usar os mecanismos da linguagem eh tao desesperadoramente imbecil que eu nao sei nem como comecar a xingar voces dois (Thiago Senna, jprogrammer).

Cv referente o reflection na prática é amelhor idea.
Mas conceitualmente não é legal, pois exige uma certa gambiarra…
Tem O problema do SecurityManager e RunTimePermission.

Deixe a gente filosofar. Se a gente depois ganhar o premio NOBEL em Java não vamos dividir com vc… :lol:

cv:

Sim, eh ridiculo. Toma um puxa de orelha.

Serializar dados em XML pra transferir de uma classe pra outra so pq vc nao sabe usar os mecanismos da linguagem eh tao desesperadoramente imbecil que eu nao sei nem como comecar a xingar voces dois (Thiago Senna, jprogrammer).

Então o motivo deste mecanismo ser uma bosta é por causa da serialização dos dados??? hummmmm… entendi!

Isso só confirma que se o DTO estiver de quatro, por cima, em baixo ou de ladinho ele sempre será uma bosta!!!

Acho q aprendi a lição!
Vou ver se arrumo outra piada para ganhar a jaqueta!

Abraços!
Thiago

renato3110:

1) Se o campo é private, o DAO não tem acesso, certo?
2) Se fosse public, como é você que faz o DAO, você sabe o que não pode salvar, é VOCÊ determinando como persistir certo?

:oops: Acho que entendi o que tu tava querendo dizer… vou apagar da mensagem hehehehhe

cv:

Sim, eh ridiculo. Toma um puxa de orelha.

Serializar dados em XML pra transferir de uma classe pra outra so pq vc nao sabe usar os mecanismos da linguagem eh tao desesperadoramente imbecil que eu nao sei nem como comecar a xingar voces dois (Thiago Senna, jprogrammer).

Aí, o cv não tá parecendo o Pai Mei?? :lol: :lol:

jprogrammer, fiquei fritando meu cérebro e acabei chegando praticamente na mesma solução do artigo killing the getters and setters
E cara, mesmo usando Hibernate, há momentos em que, sem a arquitetura que estamos tentando atingir, getters/setters são necessários. Portanto, a discussão não está tão filosófica assim.

cv, vai pro pub relaxar

Se quisermos ter uma arquittura decente temos que fritar mesmo o cérebro.
Agora se a gente pensar que replicando as entidades para as classes é programar OO vamos seguir em frente.
Eu tinha esse pensamento foi aqui no GUJ que fui me cataquizando…

O C++ tem uma papo de classes amigas, seria bom se o java tivesse isso.

Olá,

Concordo Rafael, “arquitetura generica” é um ninho de bugs e dor de cabeça. O cara NUNCA consegue mapear todas as possibilidades e sempre deixa abertura para os problemas.

PS.: Estou sem net entao meio atrasado nos topicos.

]['s

jprogrammer:

S

O C++ tem uma papo de classes amigas, seria bom se o java tivesse isso.

E tem… eh o “modificador” default (aka, nenhum modificador de acesso). (pelo menos foi o que a kathy sierra disse)

Rafael

Estou falando para pacotes diferentes.
Tavlez eu tenha falado bosta.
Naõ manjo muito de C++.

Não, selective export permite que você exponha determiandos métodos para determiandas classes. Assim você poderia expôr algumas consultas diretas á atributos pros DAOs, seme xpô-las aos clientes e sem bagunçar pacotes

Thiago… eu sei que vou me arrepender, mas…

olhe o pattern memento.

Shoes ainda bem que vc chegou ao tópico.
Fale mais sobre isso.
EDIT: me refiro ao selective export
Seria o ÉDEN.

Se possível post algum código.

Shoes:

Thiago… eu sei que vou me arrepender, mas…

olhe o pattern memento.

hehe… o nome desse pattern parece nome de sopinha! :lol: brincadeira!

Vou dar uma olhada sim Philip! Vou ver agora inclusive! Mas pq vc disse que se arrependeria?

Abraços!
Thiago

Pelo que eu entendi esse Memento não serve apenas para serialização.
Serve para externelizar os atributos sem ter que estruprar a classe.

Poderia então ter um DAOMemento ?

OBS: O problema é o nome do pattern.
Não tinha uma nome mais bonito ?

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

Philip:

Medod e vc pensar num memento baseado em XML brincadeira, é tendo idéias ridículas que se aprende, que diga eu com o Cereal.

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?

MementoGenerator.getXmlMemento(aluno);
MementoGenerator.getPropertiesMemento(aluno);
MementoGenerator.getGenericObjectMemento(aluno); //viagem
MementoGenerator.getUmaIdeiaMelhorMemento(aluno);

Thiago Senna:

Ou seja… ao invés daquela idéia se chamar XmlDTOGenerator ele poderia se chamar XmlMementoGenerator…???

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
   }
}

pcalcado:

Thiago Senna:

Ou seja… ao invés daquela idéia se chamar XmlDTOGenerator ele poderia se chamar XmlMementoGenerator…???

Eu sabia que ia me arrepender… :lol:

Não, esqueça XML, para que você precisaria dele?

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.

jprogrammer:

Pica um HashMap maluco !!!

boa…

<blockquote>Aluno aluno = new Aluno();

// seta dados do aluno

AlunoDAO dao = new AlunoDAO();

dao.create(HashMapMementoGenerator.createMemento(aluno));

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.

Topico travado. Nao ia sair mais nada dessa discussao, de qualquer forma.

jprogrammer, voce esta sendo gentilmente convidado a tomar um pouco de simancol.

jprogrammer:

renato3110 cara se vc não tá entendendo o tópico saia fora.
O negocio tá ficando alto nível…

:shock:

Jprogrammer … acho que teu alto nivel ta meio baixo para os padroes :roll: