Apostilas em PDF – 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).