Duvidas sobre POO em um sistema de controle de vendas

6 respostas
diegohsi

Ola pessoal,
estou desenvolvendo um sistema de vendas simples, e estou com dúvidas em certas implementações, estou usando MVC (seguindo um tutorial). Vamos as minhas duvidas:

Só para voces terem uma idéia do sistema:
Faço cadastro de clientes Fisicos e Juridicos. Faço vendas pra eles, Eles podem me pagar mensalmente, adiantado ou a prazo, se for adiantado toda venda é debitada de seu saldo, caso contrario, é inserida na sua conta. Logo, terei que cadastrar clientes fisicos/juridicos, controlar as vendas e o caixa. basicamente isso.

A princípio a minha dúvida é a seguinte (creio que vão surgir outras):
Tenho minhas classes Cliente, Fisica, Juridica, nas quais Fisica e Juridica extende Cliente(abstrata), logo tenho minhas classes Dao, GenericDao(Abstrata), FisicaDao, e JuridicaDao, e tabém tenho métodos em comum como por exemplo insert(), update(), delete(). Todos são praticamente iguais, contudo, a única diferença que eles possuem, são o atributo CPF para Fisica e CNPJ para Juridica. Gostaria de saber qual a melhor forma de projetar minhas classes/Interfaces para que eu não precise ficar repetindo os códigos desses métodos.

desculpem me se não fui claro o bastante.

6 Respostas

d34d_d3v1l

diegohsi:
Ola pessoal,
estou desenvolvendo um sistema de vendas simples, e estou com dúvidas em certas implementações, estou usando MVC (seguindo um tutorial). Vamos as minhas duvidas:

Só para voces terem uma idéia do sistema:
Faço cadastro de clientes Fisicos e Juridicos. Faço vendas pra eles, Eles podem me pagar mensalmente, adiantado ou a prazo, se for adiantado toda venda é debitada de seu saldo, caso contrario, é inserida na sua conta. Logo, terei que cadastrar clientes fisicos/juridicos, controlar as vendas e o caixa. basicamente isso.

A princípio a minha dúvida é a seguinte (creio que vão surgir outras):
Tenho minhas classes Cliente, Fisica, Juridica, nas quais Fisica e Juridica extende Cliente(abstrata), logo tenho minhas classes Dao, GenericDao(Abstrata), FisicaDao, e JuridicaDao, e tabém tenho métodos em comum como por exemplo insert(), update(), delete(). Todos são praticamente iguais, contudo, a única diferença que eles possuem, são o atributo CPF para Fisica e CNPJ para Juridica. Gostaria de saber qual a melhor forma de projetar minhas classes/Interfaces para que eu não precise ficar repetindo os códigos desses métodos.

desculpem me se não fui claro o bastante.

Ta usando Hibernate? Se estiver, o GenericDAO iria resolver este problema para você. (Se ele for realmente genérico).
:smiley:

rmendes08

Como o colega falou, se você utilizar a JPA você elimina boa parte dessa repetição, pois através do mapeamento objeto-relacional ele gera todo o SQL necessário de maneira transparente. Porém, se você não puder usar um framework de persistência, você precisaria escrever seu DAO genérico de maneira que você simplesmente “setasse” as SQL’s necessárias de acordo com a especialização. Sugestão: procure pelo pattern “template method”.

diegohsi

Esta é minha classe generica

public abstract class GenericDao {
    private Connection connection;
    
    protected GenericDao() { //Utiliza protected pois apenas classes do mesmo pacote podem usa-la, seguinjdo o padrão MVC
        this.connection = new ConnectionDataBase().getConnection();
    }
    
    
    protected Connection getConnection() {
        return connection;
    }
    
    
    protected void insert(String sqlInsert, Object... parametros) throws SQLException {
        PreparedStatement pstmt = getConnection().prepareStatement(sqlInsert);
        
        for(int i = 0; i < parametros.length; i++) {
            pstmt.setObject(i+1, parametros[i]);
        }
        pstmt.execute();
        pstmt.close();
    }
    
    //Parametro id se refere ao id da coluna
    protected void update(String sqlUpdate, Object id, Object... parametros) throws SQLException {
        PreparedStatement pstmt = getConnection().prepareStatement(sqlUpdate);
        
        for(int i = 0; i < parametros.length; i++) {
            pstmt.setObject(i+1, parametros[i]);
        }
        pstmt.setObject(parametros.length+1, id);
        pstmt.execute();
        pstmt.close();
    }
    
    
    protected void delete(String sqlDelete, Object... parametros) throws SQLException {
        PreparedStatement pstmt = getConnection().prepareStatement(sqlDelete);
        
        for(int i = 0; i < parametros.length; i++) {
            pstmt.setObject(i+1, parametros[i]);
        }
        pstmt.execute();
        pstmt.close();
    }
}
diegohsi

Pessoal,
o meu problema é que minha classe FisicaDao e JuridicaDao vão ter praticamente os mesmos métodos, não consigo enxergar uma maneira de corrigir isso.

meus métodos deleteEndereco(), updateEndereco(), insertEndereco(), selectEnderecoCliente(), como eu disse não estou usando nenhum framework

Então a unica diferença nos meus métodos serão minhas consultas que se diferem apenas nas tabelas fisica e juridica.

"SELECT e, f" + "FROM endereco e, [b]fisica f"[/b] + "WHERE e.cod_endereco = f.cod_endereco" + "AND f.cod_cliente = ?";

"SELECT e, f" + "FROM endereco e,[b] juridica j"[/b] + "WHERE e.cod_endereco = j.cod_endereco" + "AND j.cod_cliente = ?";

Como podem perceber tenho praticamente a mesma coisa em metodos separados, assim ocorre em todos os metodos citados acima. Sei que poderia ser feito de uma maneira mais elegante, porem não consigo enxerga.

tnaires

Se todos possuem os mesmos atributos exceto por um, entao porque voce nao mantem apenas uma classe?
Voce pode susbstituir os metodos getCpf() e getCnpj() por um so, como getCadastroNacional(). Alem disso, voce pode acrescentar um campo “tipo” na tabela, para identificar o tipo do cliente (fisico ou juridico).

rmendes08

tnaires:
Se todos possuem os mesmos atributos exceto por um, entao porque voce nao mantem apenas uma classe?
Voce pode susbstituir os metodos getCpf() e getCnpj() por um so, como getCadastroNacional(). Alem disso, voce pode acrescentar um campo “tipo” na tabela, para identificar o tipo do cliente (fisico ou juridico).

Embora essa solução não pareça “tão OO” ela é bastante pragmática na minha opinião. Lembremos, simplicidade e praticidade antes de tudo.

Criado 30 de abril de 2012
Ultima resposta 1 de mai. de 2012
Respostas 6
Participantes 4