Orientação a Objetos: Os 4 pilares, boas práticas e pegadinhas.

Fala aí, Padawan! Hoje a missão é dominar Orientação a Objetos (OO) — um dos assuntos mais cobrados em provas de TI porque ele aparece em tudo: análise, projeto, código, padrões de projeto, manutenção e… bugs cabeludos. Se você entende OO de verdade, você não só marca a alternativa certa na prova, como também escreve sistemas mais fáceis de evoluir.

O que é OO, em português bem claro?

OO é um jeito de programar pensando em objetos do mundo real (ou do domínio do sistema). Um objeto junta dados (estado) e comportamentos (métodos) numa “caixinha” coerente. Essa caixinha é definida por uma classe, que é o “molde” para criar objetos.

Classe vs Objeto: a clássica confusão de banca

Classe: a receita do bolo (estrutura + regras).
Objeto: o bolo pronto (uma instância real da classe).
Na prova, se aparecer “instância”, “objeto” e “classe”, já acende o sabre de luz: objeto é instância de classe.

Pilar 1 — Encapsulamento (o “não mexa no meu estado!”)

Encapsular é proteger os dados internos e controlar como o mundo conversa com eles. Em vez de deixar tudo público, você expõe uma interface (métodos) que mantém o objeto consistente.

Exemplo simples: se uma conta bancária não permite saldo negativo, o método sacar() valida isso. Se o saldo fosse público, qualquer um poderia setar saldo = -999.

Encapsulamento não é “só getter e setter”, Padawan

Encapsulamento não significa “criar getters/setters para tudo”. Se você expõe tudo, você continua permitindo abuso, só com mais passos. O ideal é expor comportamentos do domínio, tipo depositar(valor), ativar(), trocarSenha(), etc.

Pilar 2 — Abstração (focar no que importa)

Abstração é reduzir complexidade: você modela só o essencial para o contexto. Exemplo: para um sistema de transporte, um “Veículo” talvez precise de velocidade, acelerar(), frear(). Não precisa modelar “quantos parafusos tem no motor”.

Abstração é o que te permite criar interfaces e classes base com um contrato bem definido.

Pilar 3 — Herança (reuso, mas com cuidado)

Herança permite que uma classe derive de outra, herdando atributos e métodos. Ajuda no reuso, mas em provas e vida real, tem um mantra importante:

Prefira composição a herança (quando fizer sentido).

Porque herança cria acoplamento forte (e é aí que nascem vários problemas clássicos que a gente vai ver já já).

Pilar 4 — Polimorfismo (o mesmo “pedido”, respostas diferentes)

Polimorfismo é quando você chama o mesmo método em tipos diferentes e cada um responde do seu jeito. Exemplo: calcularFrete() para Sedex, PAC, Transportadora. A chamada é a mesma, mas a implementação varia.

Isso permite código mais flexível: você programa contra uma abstração (interface/classe base), e não contra classes concretas.

Exemplo prático (Python) com polimorfismo “do jeito certo”

Vamos criar uma interface de pagamento e duas implementações.

Linha a linha (sem enrolação):

ABC e @abstractmethod: criam um contrato (abstração). Quem herdar precisa implementar pagar.
CartaoCredito e Pix: duas implementações diferentes para o mesmo método pagar.
finalizar_compra(pagamento: Pagamento, …): recebe a abstração Pagamento (não depende de classe concreta).
pagamento.pagar(valor): aqui está o polimorfismo — a chamada é igual, mas o comportamento muda conforme o tipo real do objeto.

Boas práticas campeãs de prova: SOLID (visão geral)

OO bem feito normalmente caminha com SOLID:

S (Single Responsibility): uma classe com um motivo principal para mudar.
O (Open/Closed): aberto para extensão, fechado para modificação (polimorfismo ajuda).
L (Liskov Substitution): se B herda de A, B deve poder substituir A sem quebrar o sistema.
I (Interface Segregation): interfaces pequenas e específicas.
D (Dependency Inversion): depender de abstrações, não de concretudes.

Mesmo que a questão não cite SOLID, ela costuma cobrar o efeito dele.

“Fragile Base Class Problem” (o terror da herança)

Esse problema acontece quando você tem uma classe base muito usada e muda algo nela (mesmo “pequeno”), e várias classes filhas quebram de maneiras inesperadas.

Por quê?

Filhas dependem de detalhes internos da base (às vezes sem perceber).
Mudanças na base alteram invariantes, ordem de chamadas, efeitos colaterais.

Exemplo típico: classe base chama um método “sobrescrevível” dentro do construtor (__init__ / constructor). A filha sobrescreve e usa um atributo que ainda não foi inicializado. Resultado: bug fantasma.

Como mitigar:

Evite herança profunda.
Prefira composição.
Torne classes base mais “estáveis”: menos estado mutável e menos “ganchos” perigosos.
Evite chamar métodos sobrescrevíveis no construtor (em várias linguagens isso é uma armadilha).

Diamond Problem (o “diamante” da herança múltipla)

O Diamond Problem aparece em linguagens com herança múltipla (ex.: C++), quando uma classe herda de duas classes que herdam de uma mesma base:

A
/ \
B C
\ /
D

A grande treta: D tem uma cópia de A ou duas?
E quando B e C sobrescrevem algo de A: qual versão D usa?

Como linguagens lidam com isso:

C++: tem “virtual inheritance” para compartilhar a base (evitar duplicação).
Python: resolve com MRO (Method Resolution Order) (ordem de resolução de métodos). O Python usa o algoritmo C3 Linearization para ordenar as classes, priorizando a classe filha, seguida da esquerda para a direita na definição da herança
Java/C#: não permitem herança múltipla de classes, mas permitem múltiplas interfaces (pra fugir dessa confusão).

Anti-patterns comuns em OO (e que aparecem em enunciados)

God Object / Classe Deus: uma classe que faz tudo. Resultado: impossível manter.
Anemic Domain Model: classes com só dados + getters/setters, e regras jogadas em “services” gigantes.
Excesso de herança: árvore genealógica maior que novela.
Acoplamento alto e coesão baixa: classes dependem demais umas das outras e não têm foco.

Quando preferir composição (e ganhar pontos com isso)

Composição é quando seu objeto tem outro objeto, em vez de ser outro objeto por herança.

Exemplo: Carro tem um Motor. Isso tende a ser mais flexível: você troca o motor sem refazer a hierarquia inteira.

Em prova, se a alternativa falar “reduz acoplamento” e “aumenta flexibilidade”, composição costuma ser a direção correta.

Dicas rápidas para não cair em pegadinha de concurso

Herança é relação “é-um” (is-a); composição é “tem-um” (has-a).
Encapsulamento não é “getter/setter em tudo”.
Polimorfismo normalmente aparece com “programar para interface”.
Se falar de herança múltipla e ambiguidade: Diamond Problem.

OO é muito mais do que “classe e objeto”: é um jeito de organizar sistemas com encapsulamento, abstração, herança e polimorfismo, buscando código coeso, pouco acoplado e fácil de evoluir. Só que OO também tem armadilhas clássicas, como Fragile Base Class Problem e Diamond Problem, que aparecem direto em prova e na vida real quando a herança é mal usada. Domine os pilares, aplique boas práticas (especialmente SOLID e composição), e você vira Jedi tanto no concurso quanto no código.

Vamos praticar!

FGV – 2026 – PC-PI – Perito Criminal – Informática Forense

Durante uma análise de código para um sistema bancário, o perito identificou um problema de projeto conhecido como “Fragile Base Class Problem”, típico em hierarquias de herança.

Esse problema geralmente ocorre quando

A )se tenta sobrescrever métodos privados.

B )uma modificação na superclasse afeta negativamente o comportamento de subclasses existentes.

C )uma interface é implementada sem exploração de polimorfismo.

D )se tenta herdar de uma classe marcada como final.

E )o coletor de lixo remove objetos derivados antes dos objetos base.

Gabarito: B

Justificativa: O Fragile Base Class Problem acontece quando uma mudança na superclasse (classe base) — mesmo que pareça pequena — quebra ou altera negativamente o comportamento de subclasses já existentes, porque elas dependem (às vezes sem perceber) de detalhes internos, invariantes ou ordem de execução da classe base. Isso torna a hierarquia “frágil” a mudanças.

A) Errada. Em geral, métodos privados não são sobrescritos (não fazem parte da interface herdável em muitas linguagens); isso não define o problema.

C) Errada. Implementar interface sem explorar polimorfismo pode ser má modelagem, mas não é o “Fragile Base Class”.

D) Errada. Se a classe é final, não pode herdar — isso é outra restrição (e nem chega a criar hierarquia).

E) Errada. Coletor de lixo (GC) não “remove derivados antes da base” como causa desse problema; isso não tem relação com herança frágil.

FGV – 2025 – AL-AM – Analista Legislativo – Programador

Um módulo de relatórios da Assembleia foi projetado de modo que, sempre que um novo formato de relatório é necessário, o código da classe GeradorDeRelatorio precisa ser modificado para incluir a nova lógica de exportação.

Assinale o princípio SOLID está sendo violado por esse design, e a técnica ideal de design seria ideal para corrigi-lo

A)Dependency Inversion Principle; Correção: Padrão Adapter.

B)Single Responsibility Principle; Correção: Padrão Singleton.

C)Open-Closed Principle; Correção: Padrão Strategy ou Decorator.

D)Liskov Substitution Principle; Correção: Herança.

E)Interface Segregation Principle; Correção: Facade.

Gabarito: C

Justificativa: O design descrito viola o Open-Closed Principle (OCP): entidades de software devem estar abertas para extensão e fechadas para modificação.
Se toda vez que surge um novo formato você precisa alterar a classe GeradorDeRelatorio, ela não está “fechada para modificação” — ela vira um ponto único de mudança e risco.

A correção ideal é separar a lógica de exportação em componentes extensíveis, onde novos formatos entram como novas classes, sem mexer no gerador principal — aí entram padrões como:

Strategy: cada formato de exportação vira uma estratégia (PDF, CSV, XLSX, etc.). O gerador só delega.
Decorator (em alguns cenários): permite adicionar comportamentos/capacidades ao relatório sem modificar o núcleo, embora Strategy seja o “mais direto” para escolher entre algoritmos de exportação.

Por que as outras estão erradas:

A) DIP é sobre depender de abstrações, não de concretudes; Adapter resolve incompatibilidade de interface, não “crescimento por formatos”.
B) SRP pode até estar “meio” impactado (classe fazendo coisa demais), mas o problema central descrito é ter que modificar a classe a cada extensão. Singleton não resolve isso.
D) LSP é sobre substituição correta entre base/subtipos; “usar herança” não é correção garantida (e pode piorar).
E) ISP é sobre interfaces grandes demais; Facade simplifica acesso a subsistemas, não resolve extensão por novos formatos.

FGV – 2025 – AL-AM – Analista Legislativo – Analista de Sistema

Na fase inicial da Análise Orientada a Objetos (AOO) para desenvolver um sistema de gestão de Atos Administrativos, o Analista de Sistemas está lendo o documento de requisitos. Os requisitos descrevem que um Ato é criado, enviado para Assinatura Eletrônica pelo Diretor, e posteriormente é publicado no Diário Oficial.
Os seguintes termos destacados são os candidatos mais fortes a se tornarem as Classes principais no modelo do sistema:

A )Criado, Enviado, Publicado.

B )Assinatura Eletrônica e Diário Oficial.

C )Ato, Diretor, Assinatura Eletrônica.

D )Ato, Assinatura Eletrônica, Publicado.

E )Diretor, Diário Oficial, Lendo.

Gabarito: C

Justificativa: Na fase inicial de Análise Orientada a Objetos (AOO), os candidatos mais fortes a classes geralmente vêm de substantivos do domínio (entidades e atores) e não de verbos/ações. No texto:

Ato → entidade principal do domínio (claramente uma classe).
Diretor → ator/usuário relevante (normalmente vira classe, pelo menos como papel/usuário no modelo).
Assinatura Eletrônica → conceito do domínio (pode ser uma classe, um serviço, ou um componente, mas é um forte candidato a classe/conceito).

As palavras “criado”, “enviado”, “publicado” são ações/estados/eventos, mais candidatos a métodos, eventos ou estados do fluxo do objeto, não classes principais.

Analisando as alternativas:

A) Errada. “Criado, Enviado, Publicado” são verbos/particípios → tipicamente operações/estados, não classes.
B) Parcial, mas incompleta. “Assinatura Eletrônica” e “Diário Oficial” são substantivos, porém falta o Ato, que é o núcleo do domínio.
C) Certa. Traz o núcleo (Ato), um ator forte (Diretor) e um conceito relevante (Assinatura Eletrônica).
D) Errada. “Publicado” é ação/estado; não é o melhor candidato a classe.
E) Errada. “Lendo” é ação; e faltou Ato, que é central.

FGV – 2025 – AL-AM – Analista Legislativo – Analista de Sistema

Em um sistema de controle de tramitação de proposições, a classe Proposicao contém a lógica para manipular o atributo situacao. O acesso direto ao atributo é impedido (privado), e todas as modificações são feitas por métodos públicos como avancarSituacao() e reverterSituacao(), que contêm validações de regras de negócio.

A restrição de acesso direto aos dados (situacao) e a concentração da lógica de validação dentro da própria classe Proposicao são exemplos, respectivamente, de

A )Polimorfismo e Herança.

B )Abstração e Acoplamento.

C )Acoplamento e Baixa Abstração.

D )Herança e Baixa Coesão

E )Encapsulamento e Alta Coesão.

Gabarito: E

Justificativa:

Impedir acesso direto ao atributo situação (deixando-o privado) e obrigar o uso de métodos públicos controlados é Encapsulamento: você protege o estado interno e controla como ele pode ser alterado.
Concentrar as validações e regras de negócio relacionadas a situação dentro da própria classe Proposicao indica Alta Coesão: a classe está bem “focada” em suas responsabilidades do domínio (manter e validar seu próprio estado), em vez de espalhar essa lógica por outros lugares.

Por que as demais não batem:

A) Polimorfismo/herança não têm relação direta com “atributo privado + métodos de alteração com validação”.
B) Abstração/acoplamento não descrevem esse cenário (o ponto é proteção do estado e foco da responsabilidade).
C) Acoplamento/baixa abstração não se aplicam aqui.
D) Herança e baixa coesão é o oposto do que foi descrito.

CESPE / CEBRASPE – 2025 – FUB – Técnico de Tecnologia da Informação

A respeito dos processos de desenvolvimento de software cascata e iterativo, de projeto de software orientado a objetos, de testes e de validação de software, julgue o item a seguir.

No projeto orientado a objetos, cada objeto encapsula dados e comportamentos, o que permite modificações internas sem que outros objetos sejam afetados.

Gabarito: Verdadeiro

Justificativa: Em orientação a objetos, um objeto reúne dados (atributos) e comportamentos (métodos) e, com encapsulamento, esconde detalhes internos (como a forma de armazenar/validar dados), expondo apenas uma interface pública. Assim, é possível alterar a implementação interna (por exemplo, mudar como um atributo é calculado ou validado) sem obrigar outros objetos a mudarem, desde que a interface/contrato público permaneça o mesmo.

CESPE / CEBRASPE – 2025 – FUNPRESP-EXE – Analista de Previdência Complementar – Área 8: Estatística, Ciência de Dados e Inovação

Julgue o item que se segue, a respeito de desenvolvimento de projetos digitais.

A letra O do acrônimo SOLID corresponde ao princípio da responsabilidade única.

Gabarito: Falso (F)

Justificativa: No acrônimo SOLID, a letra O corresponde ao Open/Closed Principle (Princípio do Aberto/Fechado): entidades de software devem estar abertas para extensão e fechadas para modificação.
O Princípio da Responsabilidade Única é a letra S (Single Responsibility Principle).