Questão de Arquitetura de Software — Padrões de projeto (Design Patterns) — FCC 2016
Arquitetura de Software›Padrões de projeto (Design Patterns)
Código
fc034077
Banca
FCC
Órgão
TRT - 20ª REGIÃO (SE)
Ano
2016
Nível
Médio
Cargo
Técnico Judiciário - Tecnologia da Informação
Um desenvolvedor precisa utilizar um padrão de projeto para interceptar e manipular requisições HTTP de entrada de usuários ao sistema web, e respostas de saída através de filtros de pré-processamento e pós-processamento. Além disso, precisa utilizar outro padrão de projeto capaz de separar as regras de negócio da aplicação das regras de acesso ao banco de dados, permitindo assim centralizar em classes específicas, as operações de conexão ao banco de dados e realização de operações SQL. Os padrões de projeto que o desenvolvedor terá que utilizar são
AFront Controller e Data Transfer Object.
BApplication Filter e Data Session Façade
CIntercepting Filter e Data Access Object.
DController Helper e Data Manager Object.
EApplication Controller e Data Persistent Object.
Revelar gabarito e comentário▾
GabaritoC — Intercepting Filter e Data Access Object.
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”.
Padrões de projeto: Intercepting Filter e DAO
Gabarito: letra C. O primeiro requisito (interceptar e manipular requisições/respostas HTTP com filtros de pré e pós-processamento) é atendido pelo padrão Intercepting Filter, que permite encadear filtros independentes para processar requisições e respostas. O segundo requisito (separar regras de negócio do acesso ao banco de dados, centralizando operações SQL) é atendido pelo padrão Data Access Object (DAO), que encapsula toda a lógica de persistência. Ambos são padrões consagrados, amplamente documentados em catálogos como Core J2EE Patterns e GoF.
A banca testa o conhecimento de padrões específicos para camadas web e de persistência, exigindo distinção entre alternativas que misturam padrões de propósito semelhante, mas com finalidades divergentes.
Padrão de Projeto
Propósito
Atende ao requisito de filtros HTTP?
Atende ao requisito de separação BD/Regras de Negócio?
Intercepting Filter
Interceptar e manipular requisições/respostas HTTP com filtros de pré e pós-processamento
✅ Sim
❌ Não
Data Access Object (DAO)
Encapsular operações de acesso ao banco de dados, separando-as das regras de negócio
❌ Não
✅ Sim
Front Controller
Centralizar o tratamento de requisições, mas sem filtragem encadeada
❌ Não
❌ Não
Data Transfer Object (DTO)
Transportar dados entre camadas
❌ Não
❌ Não
Application Filter
Padrão não formalmente reconhecido para filtros
❌ Não
❌ Não
Data Session Façade
Padrão não formalmente reconhecido para abstração de BD
❌ Não
❌ Não
Controller Helper
Componente do Front Controller, não autônomo para filtros
❌ Não
❌ Não
Data Manager Object
Padrão não reconhecido para gerência de persistência
❌ Não
❌ Não
Application Controller
Padrão não formalmente reconhecido para filtros
❌ Não
❌ Não
Data Persistent Object
Padrão não reconhecido para abstração de BD
❌ Não
❌ Não
Alternativa A — ❌ Incorreta
Front Controller e Data Transfer Object (DTO). O Front Controller centraliza o tratamento de requisições, mas não realiza filtragem encadeada de pré/pós-processamento – essa é a função do Intercepting Filter. O DTO é usado para transportar dados entre camadas, não para abstrair operações de banco de dados; essa é a função do DAO.
Alternativa B — ❌ Incorreta
Application Filter e Data Session Façade. “Application Filter” não é um padrão formal reconhecido; o correto para filtros é Intercepting Filter. “Data Session Façade” também não é um padrão padrão; o equivalente para abstração de BD é o DAO.
Alternativa C — ✅ Correta ⟵ GABARITO
Intercepting Filter e Data Access Object (DAO). O Intercepting Filter permite adicionar filtros de pré-processamento (ex.: autenticação, logging) e pós-processamento (ex.: compressão) de forma modular, exatamente como descrito. O DAO encapsula o acesso a dados, isolando o código de negócio dos detalhes de SQL e conexão, conforme exigido.
Alternativa D — ❌ Incorreta
Controller Helper e Data Manager Object. Controller Helper é um componente do Front Controller, não um padrão autônomo para filtros. “Data Manager Object” não é um padrão reconhecido; o papel de gerência de persistência é do DAO.
Alternativa E — ❌ Incorreta
Application Controller e Data Persistent Object. Application Controller é similar ao Front Controller, mas foca na navegação entre views, não em filtros. “Data Persistent Object” é genérico e não corresponde a um padrão específico; o padrão consolidado é o DAO.
PEGA ESSA DICA!
Para a prova, memorize os padrões de cada camada: na camada web, o Intercepting Filter é o padrão para manipuladores de requisição/resposta encadeados; na camada de dados, o DAO é o padrão para abstrair o acesso a banco de dados. Confronte sempre com alternativas que tentam trocar por padrões de finalidade parecida, mas não idêntica.
Gabarito: letra C — Intercepting Filter e Data Access Object.