Uma aplicação de gerenciamento de pagamentos precisa oferecer suporte a diferentes métodos, como boleto, cartão de crédito e Pix. Para isso, a classe pagamento foi projetada com um método abstrato chamado processarPagamento(), que deve ser implementado de maneira específica por cada classe correspondente a um tipo de pagamento. Essa abordagem foi escolhida para aproveitar os conceitos de encapsulamento e interfaces na orientação a objetos. Nesse contexto, qual é a principal vantagem proporcionada pelo uso desses conceitos em relação à expansão e manutenção do sistema?
- A)Garantir que todos os tipos de pagamento utilizem a mesma estrutura interna de dados.
Errada, porque os tipos de pagamento não precisam compartilhar a mesma estrutura interna de dados, e sim um comportamento comum com implementações próprias.
- B)Centralizar a lógica de todos os métodos em uma única classe, reduzindo a duplicação de código.
Errada, pois a proposta não é concentrar tudo em uma única classe, mas justamente distribuir responsabilidades e evitar acoplamento excessivo.
- C)Reduzir a complexidade ao permitir que todos os métodos utilizem a mesma implementação genérica.
Errada, porque cada método de pagamento normalmente exige implementação específica, não uma solução genérica única para todos.
- D)Facilitar a adição de novos tipos de pagamento sem alterar o código existente, respeitando o princípio de substituição de Liskov.
Correta, pois permite acrescentar novos tipos de pagamento sem alterar o código já existente, com respeito à substituição segura das classes filhas.
Gabarito: D
Quando voce olha para orientação a objetos, a ideia não é só “organizar código”, mas fazer o sistema crescer sem virar um castelo de cartas. Neste caso, a classe abstrata pagamento define um contrato: cada tipo de pagamento deve saber como processarPagamento(), mas sem obrigar que todos usem a mesma lógica interna. Isso é ótimo porque boleto, cartão e Pix têm regras próprias, e cada um pode se comportar do seu jeito sem bagunçar a estrutura geral. O ganho principal aparece na manutenção e na expansão. Se amanhã surgir pagamento por carteira digital, você cria uma nova classe e implementa o método necessário, sem sair mexendo no que já funciona. Esse é exatamente o espírito do princípio aberto/fechado: a solução fica aberta para extensão, mas fechada para modificação. Na prática, menos risco de quebrar o que já estava funcionando - e menos dor de cabeça para quem mantém o sistema. A alternativa D é a correta porque traduz bem essa flexibilidade: novos tipos podem ser adicionados sem alterar o código existente, e cada classe pode ser substituída onde a abstração de pagamento for esperada. Isso conversa com o princípio da substituição de Liskov, que diz, em resumo, que uma subclasse deve poder entrar no lugar da classe base sem causar comportamento inesperado. Em outras palavras: trocar a peça sem desmontar a máquina. Encapsulamento ajuda a esconder os detalhes de implementação, e a abstração/interface define o que deve ser feito, não como. A combinação desses conceitos deixa o sistema mais limpo, mais reutilizável e muito mais fácil de evoluir.