Questão nº 71
Questão de Boas Práticas e Padrões em TIC · FCC PMSP Analista TIC 2025 (nº 71)
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, é
- Acriar uma única classe `SolicitacaoService` que gerencie as solicitações, grave no banco de dados e envie notificações aos responsáveis.
- 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.
- 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.
- 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. (alternativa correta)
- Ecriar uma classe `GestaoUnificada` que centralize todos os serviços relacionados às solicitações em um único local, para maior controle.
Resposta comentada
Gabarito Alternativa D
O Princípio da Responsabilidade Única (SRP), do SOLID, afirma que uma classe deve ter apenas uma razão para mudar, ou seja, deve ter apenas uma responsabilidade. Isso significa que cada classe deve ser especialista em uma única tarefa.
- (A) Incorreta: Esta abordagem viola o SRP, pois a
SolicitacaoServiceteria três responsabilidades distintas: gerenciar solicitações, gravar dados e enviar notificações. - (B) Incorreta: Implementar todas as funcionalidades em um único método estático é uma prática extremamente ruim, conhecida como "God Method", que viola o SRP e a maioria dos princípios de bom design, dificultando enormemente a manutenção e teste. A alegação de "melhorar a performance" é geralmente falsa nesse contexto.
- (C) Incorreta: Esta alternativa é a mais tentadora, mas também viola o SRP. Adicionar métodos para banco de dados e notificações na
SolicitacaoServicesignifica que essa classe ainda tem múltiplas responsabilidades. A "armadilha" aqui é a menção de "evitar impacto na performance" por não criar classes adicionais; para a maioria dos sistemas, os benefícios de design do SRP (manutenibilidade, testabilidade) superam qualquer impacto mínimo de performance de ter mais classes. - (D) Correta: Esta é a estratégia que está de acordo com o SRP. Cada uma das três classes propostas (
SolicitacaoService,NotificacaoService,PersistenciaService) tem uma única e bem definida responsabilidade, tornando o código mais modular, fácil de manter e testar. - (E) Incorreta: Criar uma classe
GestaoUnificadaque centraliza todos os serviços é o oposto do SRP. Essa classe se tornaria um "God Object", com muitas razões para mudar, resultando em um código complexo e difícil de gerenciar.
Fonte: FCC PMSP Analista TIC 2025 Analista de Planejamento e Desenvolvimento Organizacional - Tecnologia da Informação e Comunicação (Caderno Tipo 001). Reproduzida para fins de estudo.