Pular para o conteúdo principal

Questão de Arquitetura de Software — Arquitetura de Software — FCC 2025

Arquitetura de SoftwareArquitetura de Software
Código
fc073228
Banca
FCC
Órgão
Prefeitura de São Paulo - SP
Ano
2025
Nível
Superior
Cargo
Analista de Planejamento e Desenvolvimento Organizacional Tecnologia da Informação e Comunicação
Uma equipe de desenvolvimento de software de uma prefeitura está criando um sistema para gestão de solicitações de serviços urbanos. Durante a análise inicial, foi definido que o código deve seguir o Single Responsibility Principle (SRP) do SOLID. A estratégia que a equipe pode adotar, que está de acordo com o SRP, é
  1. Acriar uma única classe SolicitacaoService que gerencie as solicitações, grave no banco de dados e envie notificações aos responsáveis.
  2. BImplementar todas as funcionalidades do sistema de solicitações em um único método estático, a fim de facilitar a manutenção e melhorar a performance da aplicação.
  3. Cadicionar métodos na classe SolicitacaoService para gerenciar o banco de dados e enviar notificações, evitando a criação de classes adicionais que podem impactar na performance da aplicação.
  4. Ddividir o código em três classes: SolicitacaoService para gerenciar as solicitações, NotificacaoService para envio de notificações e PersistenciaService para gerenciar interações com o banco de dados.
  5. Ecriar uma classe GestaoUnificada que centralize todos os serviços relacionados às solicitações em um único local, para maior controle.
Revelar gabarito e comentário

GabaritoD — dividir o código em três classes: SolicitacaoService para gerenciar as solicitações, NotificacaoService para envio de notificações e PersistenciaService para gerenciar interações com o banco de dados.

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”.

Single Responsibility Principle (SRP)

Gabarito: letra D. O SRP determina que uma classe deve ter um único motivo para mudar, ou seja, deve ser responsável por uma única funcionalidade. A alternativa D divide o sistema em três classes com responsabilidades distintas (gerenciar solicitações, notificações e persistência), respeitando o princípio. As demais alternativas concentram múltiplas responsabilidades em uma única classe ou método, violando o SRP.

Alternativa A — ❌ Incorreta

Criar uma única classe SolicitacaoService que gerencia solicitações, grava no banco e envia notificações viola o SRP, pois a classe teria três motivos para mudar (alterações nas regras de negócio, na persistência ou nas notificações).

Alternativa B — ❌ Incorreta

Implementar todas as funcionalidades em um único método estático centraliza tudo em um ponto, violando a separação de responsabilidades e dificultando manutenção e testabilidade.

Alternativa C — ❌ Incorreta

Adicionar métodos de banco e notificações na mesma classe SolicitacaoService também concentra responsabilidades, indo contra o SRP.

Alternativa D — ✅ Correta ⟵ GABARITO

A divisão em SolicitacaoService, NotificacaoService e PersistenciaService garante que cada classe tenha uma única responsabilidade, facilitando manutenção e evolução independente.

Alternativa E — ❌ Incorreta

Centralizar todos os serviços em uma única classe GestaoUnificada repete o erro de concentrar múltiplas responsabilidades, violando o SRP.

PEGA ESSA DICA!

Lembre-se de que o SRP é sobre coesão: uma classe deve fazer uma coisa e fazê-la bem. Na hora da prova, desconfie de alternativas que colocam várias funções (negócio, persistência, notificação) em uma mesma classe.

Link permanente: /questoes/fc073228