Persistir atributos privados

This message was edited 1 time. Last update was at 02/05/2005 16:06:53

Não vejo porque isso traria muitas chamadas ao banco.
Posso ter um factory global e controlar conexao e transação a partir dele.

Mas o que eu acho esquisito de classes que tem métodos de negócios é quando eu tenho agregação.

Isso fica estranho ou é só frescura (rs...) ?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Tá estranho sim! Não seria melhor que dentro do método salvar de funcionario tivesse uma chamada para salvar o departamento?

Hmm, isso depende de como você quer implementar a semântica de cascateamento.

Se salvar o funcionario implica em salvar o departamento, sim.

Eu acho que manter o código que faz pensistencia no mesmo lugar que está o negocio uma caca.

E se a implementação de persistencia ficar toda separada em um objeto separado e se usar agregação/herança para dar acesso a esses dados no modelo.

O código não ficar mais claro com isso já que java não suporta herança múltipla nem visibilidade de herança (herança privada do c++ faz muita falta

).

This message was edited 2 times. Last update was at 02/05/2005 16:52:46

No caso não estou salvando o departamento, apenas estou mostrando que ao agregar a classe Departamento a Funcionario o método de salvar
departamento também fica disponível.

Esse é o assunto do outro tópico.
Pelo conceito OO as operaçoes devem ficar juntas com os dados.
Se quisermos programar OO deve ficar mais ou menos parecido com isso.

Estão vendo como é difícil programar OO com relacional.
Várias coisas não se batem. São duas coisas que não se encaixam.
O pessoal meteu o pau no artigo da java magazine.

editado:
Tem outra coisa na classes que fazem as operações.
Os métodos de consulta.
É muito estranho criar uma instancia para depois obter instancias.
O ideal seria usar métodos estáticos para consulta.
Só que a herança já quebra.
Pois há somente "ocultação" não sobreposição.
ex:

Mas exemplifique sua ideia louds.

louds wrote:

E se a implementação de persistencia ficar toda separada em um objeto separado e se usar agregação/herança para dar acesso a esses dados no modelo.

Para que isso? Bom, usando bound properties evitamos precisar chamar save/update explicitamente e delete em alguns casos. Além disso toda lógica e dados para falar com o banco de dados fica em lugar só.

This message was edited 1 time. Last update was at 02/05/2005 17:02:14

E se eu quiser acessar diretamente um atributo que é pesistível como Nome (por ex) teria que duplicar sua declaração nas duas classes não é.

This message was edited 3 times. Last update was at 02/05/2005 17:32:59

Pensei nisso. Vejam se é tosco !

package teste.funcionario;

abstract class Funcionario
{
   protected void setId(int id);
   public int getId() { return this.id } ;

public void salvar() {
     // regras de negocio
   }
}

abstract class FuncionarioFactory
{
  public abstract Funcionario createNew();
  public abstract Funcionario find(int id);
  public static final FuncionarioFactory getInstance()
  {
    return new teste.funcionario.jdbc.FuncionariosJDBCFactory();
  }
}

package teste.funcionario.jdbc;

class FuncionariosJDBCFactory extends FuncionarioFactory
{
   public Funcionario createNew() {
      return new FuncionarioJDBC();
   }

public Funcionario find(int id)
   {
     ResultSet rs = ....

FuncionarioJDBC  f = new FuncionarioJDBC ();
     f.setId(rs.getInt("ID");
   }
}

class FuncionarioJDBC extends Funcionario
{
   protected void setId(int id) { super.setId(id) }

public void salvar() {
      setId(geraId());
      super.salvar();
      insert into ....
   }
}

FuncionarioFactory fc = FuncionarioFactory.getInstance();
Funcionario f = fc.find(1);

// faz de conta que tem
f.setNome("Maria");
f.salvar();

Notícias, artigos e o maior fórum brasileiro sobre Java