Questão de Engenharia de Software — Orientação a Objetos — FUNDATEC 2025

Princípios SOLID – Open/Closed Principle (OCP)

Gabarito: letra B. O enunciado descreve um sistema onde se deseja adicionar novos métodos de pagamento (cartão, boleto, PIX) sem modificar o código existente, garantindo baixo acoplamento e alta extensibilidade. Esse cenário corresponde exatamente ao Princípio Aberto/Fechado (OCP), que afirma que módulos devem estar abertos para extensão, mas fechados para modificação.

Princípio Aberto/Fechado (OCP):

"Um módulo (componente) deve ser aberto para a extensão, mas fechado para modificações" [Mar00].

Os demais princípios SOLID não atendem diretamente a essa necessidade:

Alternativa A — ❌ Incorreta

O Princípio da Substituição de Liskov (LSP) trata da herança e do comportamento esperado de classes derivadas, garantindo que subtipos possam substituir seus tipos base sem alterar a corretude do sistema. Não aborda a adição de novas funcionalidades sem modificar o código existente.

Alternativa B — ✅ Correta ⟜ GABARITO

O Princípio Aberto/Fechado (OCP) é exatamente o que orienta a implementação descrita: os módulos de pagamento devem ser projetados de forma a permitir a inclusão de novos métodos (extensão) sem necessidade de alterar os módulos já existentes (fechados para modificação). Isso é alcançado por meio de abstrações (interfaces ou classes abstratas) que definem o contrato, e implementações concretas para cada método.

Alternativa C — ❌ Incorreta

O Princípio da Segregação de Interfaces (ISP) recomenda que interfaces sejam específicas para cada tipo de cliente, evitando que classes sejam forçadas a implementar métodos que não utilizam. Embora importante, não está diretamente relacionado à extensibilidade sem modificação do código existente.

Alternativa D — ❌ Incorreta

O Princípio da Responsabilidade Única (SRP) indica que cada classe deve ter uma única responsabilidade (e não apenas um método público, como afirma a alternativa). Apesar de contribuir para baixo acoplamento, não resolve o problema de adicionar novos comportamentos sem alterar o código já escrito.

Alternativa E — ❌ Incorreta

O Princípio de Inversão de Dependência (DIP) estabelece que módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações. A alternativa inverte o conceito ao afirmar que "obriga todas as classes a dependerem de classes concretas" – o correto é depender de abstrações. Mesmo sendo relevante para extensibilidade, a descrição da questão se alinha mais diretamente ao OCP.