Princípios SOLID na Orientação a Objetos: o guia que todo Padawan de concursos precisa dominar

Fala aí, Padawan! Hoje vamos encarar um que é base para programação OO: os princípios SOLID. Esse conjunto de princípios ajuda a criar sistemas mais organizados, fáceis de manter, testar e evoluir. E sim, apesar do nome parecer coisa de chefão final, dá para entender numa boa.

Antes de tudo, pensa comigo: em Orientação a Objetos, não basta só criar classes, atributos e métodos. Se o código for mal organizado, ele até funciona no começo, mas depois vira uma bagunça difícil de corrigir. É aí que entram os princípios SOLID, que funcionam como boas práticas para construir software com menos acoplamento, mais clareza e maior reaproveitamento.

O termo SOLID é um acrônimo, ou seja, uma palavra formada pelas letras iniciais de cinco princípios. Cada letra representa uma ideia importante de projeto de software. Esses princípios foram popularizados por Robert C. Martin, também conhecido como Uncle Bob, e são muito cobrados em concursos que abordam engenharia de software, orientação a objetos e arquitetura de sistemas.

Vamos destrinchar isso com calma. O S significa Single Responsibility Principle, ou Princípio da Responsabilidade Única. Ele diz que uma classe deve ter apenas um motivo para mudar. Em palavras simples: uma classe deve cuidar de uma coisa só. Se uma classe faz cadastro, gera relatório, envia e-mail e grava log, ela está acumulando responsabilidades demais.

Imagine uma classe chamada UsuarioService que cadastra usuário, valida CPF, envia e-mail de boas-vindas e ainda gera relatório em PDF. Isso é um forte indício de violação do SRP. O ideal seria separar essas responsabilidades em classes diferentes, como uma para cadastro, outra para validação, outra para envio de e-mail e assim por diante. Isso facilita manutenção e testes.

O O é de Open/Closed Principle, ou Princípio Aberto/Fechado. Ele afirma que entidades de software devem estar abertas para extensão, mas fechadas para modificação. Traduzindo: você deve conseguir adicionar novos comportamentos ao sistema sem precisar ficar alterando o código que já funciona, diminuindo o risco de quebrar funcionalidades antigas.

Pensa num sistema de cálculo de desconto. Se cada novo tipo de cliente exigir um if novo dentro da mesma classe, o código vai crescer de forma descontrolada. Uma solução melhor seria criar uma abstração para desconto e implementar comportamentos específicos em classes separadas. Assim, para adicionar um novo desconto, você cria uma nova classe, em vez de mexer em uma classe central já consolidada.

O L representa o Liskov Substitution Principle, ou Princípio da Substituição de Liskov. Esse nome assusta, mas a ideia é bem prática: uma classe filha deve poder substituir a classe pai sem causar comportamento inesperado. Em outras palavras, a herança precisa respeitar o contrato definido pela superclasse.

Um exemplo clássico é a relação entre Ave e Pinguim. Se a classe Ave tiver um método voar(), e Pinguim herdar de Ave, teremos um problema, porque pinguins são aves, mas não voam. Nesse caso, a modelagem está ruim. O erro não está no pinguim, mas na abstração criada. Isso mostra que nem toda relação do mundo real deve ser traduzida diretamente para herança no código.

O I é de Interface Segregation Principle, ou Princípio da Segregação de Interfaces. Ele diz que uma classe não deve ser obrigada a implementar métodos que não usa. Em termos simples: é melhor ter interfaces pequenas e específicas do que uma interface gigante com um monte de obrigações desnecessárias.

Imagine uma interface chamada Trabalhador com métodos programar(), testar(), gerenciarProjeto() e configurarServidor(). Nem toda classe que representa um trabalhador precisará de tudo isso. Um testador, por exemplo, talvez não programe nem configure servidor. Isso obriga classes a implementarem comportamentos artificiais, o que é péssimo para o projeto.

Por fim, o D significa Dependency Inversion Principle, ou Princípio da Inversão de Dependência. Esse é um dos mais importantes em arquitetura. Ele diz que módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações. Em linguagem direta: em vez de uma classe depender diretamente de outra classe concreta, ela deve depender de uma interface ou abstração.

Isso torna o sistema mais flexível. Se uma classe de pagamento depende diretamente de PagamentoPix, fica difícil trocar depois para PagamentoCartao ou PagamentoBoleto. Mas se ela depende de uma abstração, como MetodoPagamento, qualquer implementação concreta pode ser usada sem quebrar a estrutura principal do sistema.

Em concursos públicos, as questões sobre SOLID costumam aparecer de três formas. A primeira é conceitual, cobrando o significado de cada princípio. A segunda traz um trecho de código e pergunta qual princípio foi violado. A terceira compara SOLID com boas práticas de orientação a objetos, como encapsulamento, herança, coesão e acoplamento. Então, dominar os conceitos e identificar exemplos práticos é o caminho.

Outro ponto importante, Padawan: SOLID não é regra mágica que precisa ser aplicada de forma cega em qualquer sistema minúsculo. O objetivo é melhorar a qualidade do software. Em sistemas muito simples, exagerar em abstrações pode até atrapalhar. A maturidade está em saber quando aplicar, por que aplicar e qual problema aquilo resolve.

Também vale lembrar que SOLID conversa muito com outros temas de prova, como padrões de projeto, refatoração, testes unitários e arquitetura em camadas. Quando você entende SOLID, fica mais fácil compreender por que certos padrões, como Strategy, Factory e Dependency Injection, são tão valorizados no desenvolvimento orientado a objetos.

Pronto para o próximo desafio, Padawan? Então bora materializar isso resolvendo questões, porque conhecimento de concurso só fica afiado mesmo quando a teoria encontra a prática.

Instituto Consulplan – 2025 – TJ-RO – Analista Judiciário – Analista de Sistemas

O Tribunal de Justiça do Estado de Rondônia (TJRO) está desenvolvendo um novo sistema para integrar diferentes bases de dados judiciais e garantir maior interoperabilidade entre sistemas. Para isso, foi adotada uma abordagem orientada a objetos, com o uso de princípios como SOLID e padrões de projeto. Sobre os conceitos fundamentais de SOLID e padrões de projeto, assinale a afirmativa correta. 

A) O padrão Factory Method é indicado para evitar a criação de objetos em tempo de execução.

B) O padrão Singleton é utilizado para criar objetos que podem ser instanciados várias vezes durante a execução do programa.

C) O princípio da responsabilidade única (SRP) determina que uma classe deve ter apenas uma razão para mudar, promovendo coesão. 

D) O princípio de segregação de interface recomenda que todas as classes utilizem interfaces únicas e extensas para consolidar suas dependências. 

E) O princípio de substituição de Liskov (LSP) recomenda que subclasses adicionarem comportamentos que alteram as funcionalidades das superclasses. 

Gabarito: C

A) Errada. O Factory Method não evita a criação de objetos em tempo de execução. Na verdade, ele organiza e encapsula essa criação, deixando o código mais flexível. A ideia é delegar a criação do objeto para um método específico, evitando acoplamento direto com classes concretas.

B) Errada. O Singleton faz justamente o contrário: ele garante que exista apenas uma única instância de uma classe durante a execução do programa, com um ponto global de acesso.

C) Correta. O princípio da responsabilidade única (SRP) determina que uma classe deve ter apenas uma razão para mudar, promovendo coesão.

Essa é a definição clássica do SRP (Single Responsibility Principle). Uma classe deve ter uma única responsabilidade principal, ou seja, um único motivo para sofrer alteração. Isso melhora a coesão, que é quando os elementos da classe trabalham em torno de um mesmo objetivo.

D) Errada. O ISP (Interface Segregation Principle) defende exatamente o oposto. Ele diz que é melhor ter interfaces pequenas e específicas do que interfaces grandes e genéricas que forçam classes a implementar métodos que não precisam.

E) Errada. O LSP (Liskov Substitution Principle) diz que uma subclasse deve poder substituir a superclasse sem quebrar o comportamento esperado. Ou seja, a subclasse não deve mudar a essência do contrato herdado de forma incompatível.

FEPESE – 2023 – EPAGRI – Analista de Sistemas

Quando desenvolvemos código baseado em uma arquitetura limpa, logo pensamos em princípios SOLID.
Assinale a alternativa que exemplifica corretamente o OCP (princípio de Aberto/Fechado) em SOLID. 

A )Cada módulo de software deve ter uma, e apenas uma, razão para mudar. 

B )Partes intercambiáveis , devem aderir a um contrato que permita substituir as partes. 

C )Projetar sistemas que permitam mudança pela adição de um novo código. 

D )O código de alto nível não deve depender dos detalhes do código de baixo nível. 

E )Os projetistas devem evitar depender de coisas que não usam. 

Gabarito: C

A) Errada. Essa alternativa descreve o SRP (Single Responsibility Principle), ou Princípio da Responsabilidade Única. A ideia é que cada módulo, classe ou componente tenha apenas um motivo para mudar, e não o conceito de aberto/fechado.

B) Errada. Essa alternativa está relacionada ao LSP (Liskov Substitution Principle), que trata da substituição de partes ou subclasses por outras compatíveis, desde que respeitem o mesmo contrato sem quebrar o comportamento esperado do sistema.

C) Correta. O OCP (Open/Closed Principle) defende que o sistema deve estar aberto para extensão e fechado para modificação. Em termos práticos, isso significa projetar sistemas que permitam mudanças por meio da adição de novo código, sem precisar alterar o código já existente e estável.

D) Errada. Essa alternativa se refere ao DIP (Dependency Inversion Principle), que afirma que o código de alto nível não deve depender diretamente dos detalhes de baixo nível, mas sim de abstrações.

E) Errada. Essa alternativa representa o ISP (Interface Segregation Principle), segundo o qual os projetistas devem evitar depender de interfaces, métodos ou estruturas que não utilizam.

INSTITUTO AOCP – 2025 – MPE-RS – Técnico do Ministério Público – Informática

Os padrões arquiteturais de software definem diretrizes para a organização e a estruturação de sistemas, facilitando a escalabilidade, a manutenção e a reutilização de código. O SOLID é um conjunto de princípios de design que auxiliam na criação de software mais flexível e sustentável. Em relação ao Open/Closed Principle (OCP), um dos princípios do SOLID, assinale a alternativa correta.  

A )Aberto para substituição, fechado para segregação. 

B )Aberto para extensão, fechado para modificação. 

C )Aberto para segregação, fechado para inversão. 

D )Aberto para inversão, fechado para extensão. 

E )Aberto para  modificação, fechado para substituição.

Gabarito: B

A) Errada. Essa alternativa mistura termos que não correspondem ao Open/Closed Principle. OCP não fala em “aberto para substituição” nem “fechado para segregação”.

B) Correta. O OCP (Open/Closed Principle) estabelece que entidades de software devem estar abertas para extensão e fechadas para modificação. Isso significa que o sistema pode ganhar novos comportamentos sem que seja necessário alterar o código já existente e estável.

C) Errada. “Segregação” está ligada ao ISP (Interface Segregation Principle), enquanto “inversão” remete ao DIP (Dependency Inversion Principle). Portanto, essa alternativa não define o OCP.

D) Errada. “Aberto para inversão, fechado para extensão” não corresponde a nenhum enunciado correto do SOLID. No caso do OCP, a ideia correta é permitir extensão, e não fechá-la.

E) Errada. Essa alternativa inverte completamente o conceito. O OCP não defende que o software seja aberto para modificação. Pelo contrário: ele deve ser fechado para modificação, evitando alterações frequentes no código já validado.

CESPE / CEBRASPE – 2022 – BANRISUL – Quality Assurance (QA) e Analistas de Teste

Julgue o item a seguir, com relação aos conceitos de SOLID.

Os princípios de programação orientada a objetos que correspondem aos princípios SOLID são: criador (creator), especialista na informação (information expert), controlador (controller), polimorfismo (polymorphism), fabricação pura (pure fabrication).

Gabarito: Errado

A afirmativa está errada porque os itens citados — creator, information expert, controller, polymorphism e pure fabrication — não pertencem ao SOLID. Esses conceitos estão associados aos padrões GRASP (General Responsibility Assignment Software Patterns), que também são usados em orientação a objetos, mas são diferentes dos princípios SOLID.

Os princípios corretos do SOLID são:

S – Single Responsibility Principle
Princípio da Responsabilidade Única

O – Open/Closed Principle
Princípio Aberto/Fechado

L – Liskov Substitution Principle
Princípio da Substituição de Liskov

I – Interface Segregation Principle
Princípio da Segregação de Interfaces

D – Dependency Inversion Principle
Princípio da Inversão de Dependência

FGV – 2024 – DATAPREV – ATI – Desenvolvimento de Software

Em um projeto de software utilizando orientação a objetos, foi implementado o seguinte código em Java:

Com base no princípio de Substituição de Liskov (L), que faz parte dos princípios SOLID, em relação à implementação do método emitirSom, assinale a opção correta. 

A )A classe Cachorro não pode sobrescrever o método emitirSom, pois isso viola o princípio da Substituição de Liskov. 

B )O princípio da Substituição de Liskov é violado porque a classe Cachorro altera o comportamento do método emitirSom herdado de Animal. 

C O código está de acordo com o princípio da Substituição de Liskov, já que a classe Cachorro pode ser usada no lugar da classe Animal sem comprometer a corretude do programa. 

D )O princípio da Substituição de Liskov exige que o método emitirSom de Cachorro seja exatamente igual ao de Animal. 

E )A implementação fere o princípio da Substituição de Liskov porque o método sobrescrito deve lançar uma exceção quando chamado. 

Gabarito: C

A) Errada. A classe Cachorro pode, sim, sobrescrever o método emitirSom(). Sobrescrever método em herança é algo comum na orientação a objetos e não viola, por si só, o Princípio da Substituição de Liskov. A violação só ocorreria se a subclasse quebrasse o contrato esperado da superclasse.

B) Errada. O fato de a classe Cachorro alterar o comportamento do método herdado não significa automaticamente violação do LSP. Em orientação a objetos, é natural que subclasses especializem comportamentos. O problema seria se Cachorro não pudesse ser usado no lugar de Animal sem gerar comportamento incorreto ou inesperado.

C) Correta. O código está de acordo com o Princípio da Substituição de Liskov, porque a classe Cachorro pode ser usada no lugar da classe Animal sem comprometer a corretude do programa. Um Cachorro continua sendo um Animal, e o método emitirSom() mantém a ideia esperada do contrato: o animal emite um som, ainda que esse som seja mais específico.

D) Errada. O LSP não exige que o método da subclasse seja exatamente igual ao da superclasse. Ele exige que a subclasse preserve o comportamento esperado pelo contrato da classe base, sem quebrar a lógica do sistema.

E) Errada. Não existe regra no LSP dizendo que um método sobrescrito deve lançar exceção quando chamado. Na verdade, adicionar comportamentos inesperados como exceções indevidas pode até ser um indício de violação do princípio, caso isso impeça a substituição correta da superclasse pela subclasse.