Questão de Engenharia de Software — Orientação a Objetos — FUNDATEC 2025
Engenharia de Software›Orientação a Objetos
Código
qg474983
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Nível
Superior
Cargo
Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Em um módulo de faturamento eletrônico de um órgão federal, busca-se alta manutenibilidade e testabilidade segundo as boas práticas de projetos em 00. Considerando esse contexto, assinale a alternativa correta sobre a coesão e o acoplamento.
AO baixo acoplamento e a alta coesão garantem responsabilidades bem delimitadas por classe e dependências mínimas entre módulos, reduzindo o impacto de mudanças e facilitando o isolamento de testes e reúso.
BAlta coesão tende a aumentar o acoplamento, pois classes mais focadas teriam de colaborar com mais serviços externos, elevando dependências e propagação de mudanças.
CA coesão baixa é preferível quando a classe agrega múltiplas regras de negócio, centralizando decisões para evitar "muitos componentes pequenos" e suposto overhead arquitetural.
DO acoplamento é irrelevante em 00 moderna, já que mecanismos de injeção de dependência neutralizam qualquer efeito de integração entre módulos.
EA alta coesão implica conhecer muitas outras classes, pois a especialização exigiria orquestrar diversos serviços externos para entregar valor.
Revelar gabarito e comentário▾
GabaritoA — O baixo acoplamento e a alta coesão garantem responsabilidades bem delimitadas por classe e dependências mínimas entre módulos, reduzindo o impacto de mudanças e facilitando o isolamento de testes e reúso.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Coesão e Acoplamento em Orientação a Objetos
Gabarito: letra A. O baixo acoplamento e a alta coesão são os dois pilares do projeto orientado a objetos de qualidade. Eles garantem que cada classe tenha responsabilidades bem definidas e que as dependências entre módulos sejam mínimas, o que reduz o impacto de mudanças e facilita o isolamento de testes e o reúso.
A banca testa se o candidato compreende a relação inversa entre coesão e acoplamento: {{quanto maior a coesão, menor o acoplamento}} (e vice-versa). As alternativas B, C, D e E distorcem propositalmente essa lógica.
Atributo
Alta Coesão
Baixo Acoplamento
Relação entre Coesão e Acoplamento
Impacto na Manutenibilidade
Definição
Cada classe tem responsabilidade única e bem delimitada
Dependências mínimas entre classes/módulos
Quanto maior a coesão, menor o acoplamento (relação inversa)
Reduz impacto de mudanças e facilita isolamento de testes
Efeito sobre dependências
Reduz necessidade de serviços externos
Minimiza propagação de mudanças
Alta coesão não aumenta acoplamento (ao contrário do que afirma a alternativa B)
Facilita reúso de componentes
Consequência de baixa qualidade
Classe "Deus" com múltiplas regras (anti-padrão)
Dependências excessivas entre módulos
Baixa coesão tende a aumentar acoplamento
Dificulta manutenção, entendimento e teste
Papel da injeção de dependência
Não substitui a necessidade de baixo acoplamento
Reduz acoplamento, mas não o torna irrelevante
Ferramenta para gerenciar dependências, não para ignorá-las
Ainda é necessário projetar com baixo acoplamento
Projeto OO: Alta coesão (Responsabilidade única, Menos dependências, Fácil manutenção); Baixo acoplamento (Dependências mínimas, Menor propagação de mudanças, Isolamento de testes); Relação (Alta coesão → baixo acoplamento, Baixa coesão → alto acoplamento)
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa descreve exatamente o que se espera de um bom projeto: alta coesão (cada classe faz bem uma única coisa) e baixo acoplamento (classes são independentes umas das outras). Isso resulta em responsabilidades delimitadas, menor propagação de mudanças e maior facilidade para testar e reutilizar componentes. A literatura clássica de engenharia de software (Pressman, Sommerville) aponta que essas duas métricas são as mais importantes para a manutenibilidade.
Alternativa B — ❌ Incorreta
Afirma que alta coesão tende a aumentar o acoplamento. Isso é falso. Na verdade, uma classe com alta coesão (focada em uma única responsabilidade) precisa de menos dependências externas, pois não mistura responsabilidades. O aumento de acoplamento ocorre quando a coesão é baixa (classe que faz muitas coisas diferentes acaba dependendo de vários serviços). A alternativa inverte a relação correta.
Alternativa C — ❌ Incorreta
Defende que baixa coesão seria preferível quando a classe agrega múltiplas regras de negócio, centralizando decisões. Isso contraria o princípio da responsabilidade única (SRP). Classes com baixa coesão são difíceis de manter, entender e testar; qualquer mudança em uma regra pode afetar as demais. A centralização citada é, na verdade, um anti-padrão de projeto (classe Deus). O overhead de ter muitos componentes pequenos e coesos é compensado pela manutenibilidade.
Alternativa D — ❌ Incorreta
Afirma que o acoplamento é irrelevante na OO moderna por causa da injeção de dependência. A injeção de dependência reduz o acoplamento, mas não o elimina nem o torna irrelevante. O acoplamento continua sendo uma preocupação central – a injeção de dependência é uma técnica para gerenciar o acoplamento, não para ignorá-lo. Dizer que é "irrelevante" é um erro grave.
Alternativa E — ❌ Incorreta
Repete o erro da B: diz que alta coesão implica conhecer muitas outras classes. A especialização (alta coesão) reduz o conhecimento sobre outros componentes, pois a classe se concentra em sua própria responsabilidade. Dependências são minimizadas. A alternativa confunde alta coesão com dispersão de responsabilidades.
Conclusão: A única alternativa que reflete corretamente a relação entre coesão e acoplamento, e os benefícios para manutenibilidade e testabilidade, é a letra A. As demais invertem conceitos ou desconsideram princípios fundamentais da orientação a objetos.