Classe para Unidade e Classe para coletividade

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Caras me surgiu uma dúvida.
Ficaria descente ter uma classe de negócio para unidade e outra para coletividade do mesmo objeto de dominio.
ex:

class Funcionario
{
public void salvar() {}
public void excluir() {}
}

class Funcionarios
{
public Funcionario obterFuncionario(int codigo) {}
public Funcionario criarNovo() {}
public void excluirPorIdade(int idade) {}
public void atualizarSalarioPorIdade(int idade,float salario) {}
}

Isso é descente ou não. Gostaria de sugestões de melhorias.

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

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

renato3110 wrote:Depois daquele tópico sobre classes de dados (que aliás o último post o Shoes não respondeu )

Link, please?

This message was edited 2 times. Last update was at 11/05/2005 13:24:33

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.

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Link: Classes de dados e classes de lógica

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

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

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 !

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

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

Ia ser massa!

E não gostei disso heheheheheh feio!

This message was edited 2 times. Last update was at 11/05/2005 15:07:34

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.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

É 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)

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

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

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

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.....!!!

É.. é 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 wrote:Gostaria de mais sugestões.. (de preferencia com argumentos concretos e de quem realmente entendeu a proposta do tópico)

Sinto, mas o JForum ainda não tem a feature: 'Só receber mensagens de...'

This message was edited 1 time. Last update was at 11/05/2005 16:03:32

É 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 ?

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.

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

jprogrammer wrote:É 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!!!

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