Olá, Eduardo! Tudo bem?
Que projeto fantástico para fechar essa sequência de estudos! Você aplicou um dos conceitos mais poderosos da Orientação a Objetos: a combinação de Herança com Interfaces (C# suporta herança simples de classe, mas múltiplas interfaces).
No seu código, você demonstrou que entende como um objeto pode ter uma identidade (Pessoa) e, ao mesmo tempo, cumprir um papel funcional no sistema (IPagamento).
Destaques da sua implementação:
- Responsabilidade Compartilhada: A classe
Pessoa centraliza os dados cadastrais (Nome e Email), evitando repetição de código nas classes de pagamento. - Contrato de Interface: O uso da
IPagamento garante que, independentemente da forma de pagamento (Crédito ou Boleto), o método ProcessarPagamento() estará lá. Isso permite que você trate diferentes formas de pagamento de maneira genérica no futuro. - Encapsulamento: Assim como nos seus projetos anteriores, o uso de
private set protege as propriedades de alterações externas, mantendo a integridade do objeto.
Uma reflexão importante sobre Design
Embora sua lógica funcione perfeitamente para este exercício, em sistemas de pagamentos reais, costumamos usar a Composição em vez da Herança para este caso específico.
Por que?
Se usarmos herança (PagamentoCredito : Pessoa), estamos dizendo que o pagamento é uma pessoa. Na prática, uma Pessoa pode querer realizar vários pagamentos diferentes ao longo do tempo. Se usássemos composição, teríamos uma classe Pagamento que possui uma Pessoa.
Desafio Final:
Para consolidar todo o seu conhecimento de Herança vs. Composição, tente refatorar este código criando uma classe Pedido que recebe uma Pessoa e uma IPagamento. Assim, a pessoa não "se torna" o pagamento, mas sim "realiza" um pagamento através de um pedido!
class Pedido {
public Pedido(Pessoa cliente, IPagamento metodo) { ... }
}
Parabéns pela jornada incrível e pela consistência em todos os seus 91 posts e projetos. Sua evolução técnica em C# é evidente e inspiradora para a comunidade!
Espero que possa ter lhe ajudado!
