Questão de Engenharia de Software — Geral — FUNDATEC 2025

Coesão e Acoplamento em Projetos Orientados a Objetos

Gabarito: letra A. O baixo acoplamento e a alta coesão são os princípios de projeto que 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 o reúso. A alternativa A reflete exatamente essa definição, que é a base das boas práticas de engenharia de software orientada a objetos.

Coesão e acoplamento são duas métricas de qualidade de projeto que avaliam, respectivamente, o grau de relacionamento entre os elementos internos de um módulo (classe, componente) e o grau de dependência entre módulos distintos. A alta coesão significa que os métodos e atributos de uma classe estão fortemente relacionados e focados em uma única responsabilidade bem definida. O baixo acoplamento significa que as classes dependem minimamente de outras classes, comunicando-se por interfaces estáveis e reduzindo a propagação de mudanças.

Esses dois princípios andam juntos: um sistema bem projetado busca alta coesão e baixo acoplamento. A alta coesão facilita a manutenção, pois cada classe tem um propósito claro e é mais fácil de entender, testar e modificar. O baixo acoplamento reduz o impacto de alterações, pois uma mudança em uma classe não exige modificações em várias outras. Isso também favorece o reúso, pois classes independentes podem ser utilizadas em diferentes contextos sem arrastar dependências desnecessárias.

Na prática, imagine um módulo de faturamento eletrônico. Uma classe Fatura com alta coesão seria responsável apenas por representar os dados e o cálculo do valor de uma fatura. Uma classe EmissorFiscal com baixo acoplamento dependeria de uma interface ServicoFiscal para enviar a fatura, sem conhecer os detalhes da implementação do serviço (se é um webservice da SEFAZ, um arquivo, etc.). Assim, se o serviço fiscal mudar, apenas a implementação concreta é alterada, sem impactar a classe EmissorFiscal.

A pegadinha que a banca explora neste tema é a inversão dos conceitos: afirmar que alta coesão aumenta o acoplamento, ou que baixa coesão é preferível, ou que o acoplamento é irrelevante. Todas essas afirmações contrariam os princípios fundamentais de projeto. O candidato que não domina a definição exata de coesão e acoplamento pode se confundir com a linguagem técnica e cair em uma das alternativas incorretas.

Guarde a fronteira entre coesão (foco interno) e acoplamento (dependência externa): é exatamente nela que as alternativas se dividem. A alternativa correta é a única que associa corretamente os dois conceitos aos benefícios de manutenibilidade, testabilidade e reúso.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta alternativa está correta porque descreve com precisão os benefícios do baixo acoplamento e da alta coesão. A alta coesão garante que cada classe tenha responsabilidades bem delimitadas, e o baixo acoplamento garante dependências mínimas entre módulos. Isso reduz o impacto de mudanças (pois uma alteração em uma classe não se propaga para muitas outras), facilita o isolamento de testes (pois cada classe pode ser testada de forma independente) e promove o reúso (pois classes independentes podem ser utilizadas em diferentes contextos).

Alternativa B — ❌ Incorreta

Esta alternativa inverte a relação entre coesão e acoplamento. Afirma que alta coesão tende a aumentar o acoplamento, o que é falso. Na verdade, alta coesão e baixo acoplamento são objetivos complementares e desejáveis. Uma classe com alta coesão é focada em uma única responsabilidade e, portanto, tende a ter menos dependências externas, não mais. A afirmação de que classes mais focadas colaborariam com mais serviços externos é um equívoco: a colaboração é necessária, mas o projeto busca minimizar o acoplamento por meio de interfaces estáveis e abstrações.

Alternativa C — ❌ Incorreta

Esta alternativa defende a coesão baixa, o que contraria os princípios de projeto. A baixa coesão significa que uma classe agrega múltiplas responsabilidades não relacionadas, o que dificulta a manutenção, o teste e o reúso. A justificativa apresentada (centralizar decisões para evitar "muitos componentes pequenos") não é válida, pois a modularidade e a separação de responsabilidades são fundamentais para lidar com a complexidade. Uma classe com múltiplas regras de negócio não relacionadas é um anti-padrão conhecido como "God Class" e deve ser evitada.

Alternativa D — ❌ Incorreta

Esta alternativa afirma que o acoplamento é irrelevante em OO moderna, o que é falso. O acoplamento é uma métrica fundamental de qualidade de projeto, e a injeção de dependência é uma técnica que ajuda a reduzir o acoplamento, mas não o elimina. A injeção de dependência transfere a responsabilidade de criar e fornecer dependências para um agente externo, mas as classes ainda precisam conhecer as interfaces das dependências. O acoplamento continua sendo relevante para avaliar a manutenibilidade e a testabilidade do sistema.

Alternativa E — ❌ Incorreta

Esta alternativa inverte o conceito de alta coesão. Afirma que alta coesão implica conhecer muitas outras classes, o que é falso. A alta coesão significa que os elementos internos de uma classe estão fortemente relacionados, não que a classe conhece muitas outras. A especialização não exige orquestrar diversos serviços externos; pelo contrário, uma classe coesa é focada e tende a ter menos dependências externas. A orquestração de serviços externos é uma característica de classes com baixa coesão e alto acoplamento, que é o oposto do desejado.

Gabarito: letra A