1. java
  2. android
  3. c#
  4. .net
  5. javascript
  6. php
  7. jquery
  8. html
  9. sql

Herança X composição no design de formas de pagamento

Boa tarde! Estou criando as parcelas de um acerto (venda) e a princípio implementei sob forma de herança, mesmo sabendo que teria problemas. Como a escolha da forma de pagamento será em tempo de execução vi que teria que instanciar a subclasse para acessar seus atributos específicos.

As classes:

public abstract class Parcela {

    private Long codigo;
    private Date dataEmissao;
    private Date dataVencimento;
    private BigDecimal valor;

    private Acerto acerto;
public class Dinheiro extends Parcela{

    @Override
    @Transient
    public final FormaPagamento getFormaDePagamento() {
        return FormaPagamento.DINHEIRO;
    }

}
public class Cheque extends Parcela{

    public String banco;
    public String agencia;
    public String conta;
    public String numero;
    public String cpfTitular;
    public String nomeTitular;
    public boolean cruzado;

Então, como o cheque tem atributos específicos fica difícil trabalhar com herança. A solução, que pensei, seria implementar a composição. O que se tornaria uma boa prática, inclusive. Porém não sei se o desing estaria correto da seguinte forma:

public abstract class Parcela {

    private Long codigo;
    private Date dataEmissao;
    private Date dataVencimento;
    private BigDecimal valor;

    private Acerto acerto;
        private Cheque cheque;

Assim, uma parcela não seria um cheque, mas uma parcela teria (ou não) um cheque. Uma outra dúvida é quanto ao caso de adicionar uma outra forma de pagamento como cartão. Ficaria assim:

public abstract class Parcela {

    private Long codigo;
    private Date dataEmissao;
    private Date dataVencimento;
    private BigDecimal valor;

    private Acerto acerto;
        private Cheque cheque;
        private Cartao cartao;

Se criasse uma Interface TipoPagamento para cheque, cartao e outras, eu teria que retornar null em getters como número do cheque quando estivesse tratando um cartão. Se bem que eu poderia tratar a classe abstrata Parcela como uma interface e declarar os comportamentos de getNumeroDoCheque e nas classes que não o utilizam apenas returnar null. Será que funfa, fica feio? Pois não vejo outra alternativa.

public abstract class Parcela {

    private Long codigo;
    private Date dataEmissao;
    private Date dataVencimento;
    private BigDecimal valor;

    private TipoPagamento tipoPagamento;

Quem puder dar uma força agradeço! Abçs.

  • Dinheiro é uma Parcela, Cheque é uma Parcela?

    Douglas Arantes   06 de set de 2014
  1. Você vai ver essas setas em qualquer página de pergunta. Com elas, você pode dizer se uma pergunta ou uma resposta foram relevantes ou não.
  2. Edite sua pergunta ou resposta caso queira alterar ou adicionar detalhes.
  3. Caso haja alguma dúvida sobre a pergunta, adicione um comentário. O espaço de respostas deve ser utilizado apenas para responder a pergunta.
  4. Se o autor da pergunta marcar uma resposta como solucionada, esta marca aparecerá.
  5. Clique aqui para mais detalhes sobre o funcionamento do GUJ!

3 respostas

Não é a resposta que estava procurando? Procure outras perguntas com as tags orientação-a-objetos herança ou faça a sua própria pergunta.