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

Padrões de Projeto: Strategy e Command

Gabarito: letra C. A combinação mais adequada é o padrão Strategy para encapsular os diferentes algoritmos de distribuição (volume de trabalho, especialidade, sorteio) e o padrão Command para encapsular as operações de "aplicar distribuição", "registrar log" e "confirmar operação" como objetos reutilizáveis e rastreáveis. O Strategy permite trocar a lógica de distribuição em tempo de execução sem afetar o cliente, e o Command atende ao requisito de rastreabilidade e controle de alterações.

O problema apresentado tem duas necessidades distintas: (1) encapsular algoritmos intercambiáveis de distribuição e (2) controlar e registrar operações de configuração. O padrão Strategy resolve a primeira: ele define uma família de algoritmos, encapsula cada um deles e os torna intercambiáveis, permitindo que o algoritmo varie independentemente dos clientes que o utilizam. No contexto do tribunal, cada critério de distribuição (por volume de trabalho, especialidade do magistrado ou sorteio aleatório) seria uma estratégia concreta, e o sistema poderia alternar entre elas sem modificar o código que as utiliza — exatamente o que o enunciado pede ao mencionar "flexibilidade de alterar a lógica sem afetar os demais componentes".

A segunda necessidade — "controle rigoroso de alterações na configuração de distribuição, com geração de logs e confirmação de operação" — é resolvida pelo padrão Command. O Command encapsula uma solicitação como um objeto, permitindo parametrizar clientes com diferentes solicitações, enfileirar ou registrar solicitações e suportar operações reversíveis. Ao transformar "aplicar distribuição", "registrar log" e "confirmar operação" em comandos, cada ação vira um objeto que pode ser armazenado, auditado e executado de forma controlada, atendendo à exigência de rastreabilidade do CNJ.

A combinação Strategy + Command é clássica: o Strategy define o algoritmo (o que fazer), e o Command define a operação (quando e como fazer, com registro). Enquanto o Strategy se preocupa com a variação do comportamento, o Command se preocupa com a invocação e o controle da execução. Essa separação é o que torna o sistema flexível e auditável ao mesmo tempo.

A pegadinha da banca está em misturar padrões com propósitos diferentes: Decorator (adicionar responsabilidades dinamicamente), Singleton (garantir instância única), Adapter (converter interfaces), Observer (notificação de mudanças) e Prototype (cópia de objetos). Nenhum deles, isoladamente ou em combinações erradas, atende aos dois requisitos simultaneamente. Guarde a fronteira: Strategy para algoritmos intercambiáveis, Command para operações rastreáveis — é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

O Decorator adiciona responsabilidades a um objeto dinamicamente, empilhando comportamentos — não é adequado para encapsular algoritmos intercambiáveis como critérios de distribuição. Além disso, o Singleton garante uma única instância, mas não "constrói objetos complexos passo a passo" — essa é a função do padrão Builder. A alternativa mistura os propósitos dos padrões: Decorator é estrutural, Singleton é criacional, e nenhum dos dois resolve a variação de algoritmos nem o controle de operações.

Alternativa B — ❌ Incorreta

O Adapter converte a interface de uma classe em outra interface esperada pelos clientes, permitindo que classes incompatíveis trabalhem juntas. Embora possa ser útil para integrar sistemas legados, ele não encapsula algoritmos intercambiáveis nem fornece mecanismo de log e confirmação de operações. A alternativa descreve um cenário de integração, não de variação de comportamento e rastreabilidade — que são os requisitos centrais do enunciado.

Alternativa C — ✅ Correta ⟵ GABARITO

O Strategy encapsula os algoritmos de distribuição (volume, especialidade, sorteio) em classes separadas, tornando-os intercambiáveis sem afetar o cliente. O Command encapsula as operações "aplicar distribuição", "registrar log" e "confirmar operação" como objetos, permitindo armazenamento, auditoria e execução controlada — atendendo à exigência de rastreabilidade. A combinação resolve exatamente os dois requisitos: flexibilidade de alteração da lógica e controle rigoroso das alterações.

Alternativa D — ❌ Incorreta

O Singleton garante uma única instância de uma classe, mas não resolve a variação de algoritmos nem o controle de operações. Centralizar todas as decisões em um único objeto compartilhado violaria o princípio da responsabilidade única e dificultaria a manutenção e a testabilidade. O Singleton é um padrão criacional, não comportamental — não é a solução para encapsular critérios de distribuição nem para gerar logs e confirmações.

Alternativa E — ❌ Incorreta

O Observer define uma dependência um-para-muitos entre objetos, notificando observadores quando o sujeito muda — não é adequado para encapsular algoritmos de distribuição. O Prototype cria novos objetos copiando um protótipo existente — não tem relação com atualização automática baseada em banco de dados. A alternativa descreve um cenário de notificação e clonagem, que não atende aos requisitos de variação de algoritmo e rastreabilidade de operações.

Gabarito: letra C