Questão de Arquitetura de Software — Padrões de projeto (Design Patterns) — FCC 2025
Arquitetura de Software›Padrões de projeto (Design Patterns)
Código
fc074044
Banca
FCC
Órgão
TRF - 4ª REGIÃO
Ano
2025
Nível
Superior
Cargo
Analista Judiciário - Área Apoio Especializado - Especialidade: Análise de Sistemas de Informação
Uma equipe de desenvolvimento está criando uma aplicação que precisa gerar diferentes tipos de relatórios (PDF, Excel ou HTML). Cada tipo de relatório requer um processo de construção complexo e especifico. Nesse cenário, o padrão de projeto criacional da Gang of Four (GoF) mais adequado para encapsular a criação de objetos complexos, permitindo a construção de diferentes representações e facilitando a adição de novos tipos de objetos sem alterar o código existente é o
ABuilder, que separa a construção de um objeto complexo de sua representação, permitindo que o mesmo processo de construção crie diferentes representações.
BPrototype, que cria novos objetos copiando uma instancia existente.
CFactory Method, que define uma interface para criar um objeto, mas permite as subclasses decidirem qual classe instanciar.
DSingleton, que garante que uma classe tenha apenas uma instancia e fornece um ponto global de acesso a ela.
EObject Pool, que mantém um conjunto de objetos prontos para uso, evitando o custo de criação repetida.
Revelar gabarito e comentário▾
GabaritoA — Builder, que separa a construção de um objeto complexo de sua representação, permitindo que o mesmo processo de construção crie diferentes representações.
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 Criacionais – Builder
Gabarito: letra A (Builder). O padrão Builder é o mais adequado quando se precisa construir objetos complexos com diferentes representações, separando o processo de construção da representação final. No cenário de geração de relatórios em PDF, Excel ou HTML, cada formato exige um processo específico, e o Builder permite encapsular essa variação sem alterar o código cliente, cumprindo exatamente o que o enunciado descreve.
A questão testa o conhecimento dos padrões criacionais da Gang of Four (GoF). O Builder se encaixa perfeitamente na descrição: “separa a construção de um objeto complexo de sua representação, permitindo que o mesmo processo de construção crie diferentes representações”. Os demais padrões não atendem a esse requisito de flexibilidade para criar múltiplas representações a partir de um mesmo processo.
Padrão (GoF)
Categoria
Problema que resolve
Adequação ao cenário (relatórios PDF/Excel/HTML)
Builder
Criacional
Separa a construção de um objeto complexo de sua representação, permitindo que o mesmo processo de construção crie diferentes representações.
✅ Mais adequado. Cada tipo de relatório (PDF, Excel, HTML) exige um processo de construção complexo e específico. O Builder encapsula essas variações sem alterar o código cliente, e novos formatos podem ser adicionados criando novos construtores concretos.
Prototype
Criacional
Cria novos objetos copiando uma instância existente (protótipo).
❌ Não atende. A clonagem replica a mesma representação, não gerando variações a partir de um mesmo processo de construção.
Factory Method
Criacional
Define uma interface para criar um objeto, mas permite que subclasses decidam qual classe instanciar.
❌ Parcialmente útil, mas não ideal. Não separa o processo de construção em etapas nem permite criar diferentes representações de um mesmo objeto complexo com a mesma flexibilidade do Builder.
Singleton
Criacional
Garante que uma classe tenha apenas uma instância e fornece um ponto global de acesso a ela.
❌ Não se aplica. O problema não é controlar o número de instâncias, mas sim construir objetos complexos com diferentes representações.
Object Pool
Criacional (não GoF clássico)
Mantém um conjunto de objetos prontos para uso, evitando o custo de criação repetida.
❌ Não se aplica. O foco é reutilização de objetos, não a construção de diferentes representações de um objeto complexo.
1Diretor coordena construtor
2Construtor define etapas
3Produto final (relatório)
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
O Builder é o padrão criacional que isola a lógica de construção de um objeto complexo em um diretor e construtores específicos. O cliente utiliza um diretor que coordena o construtor abstrato; cada construtor concreto implementa os passos para gerar uma representação diferente (PDF, Excel, HTML). Isso permite adicionar novos tipos de relatório sem modificar o código existente, apenas criando um novo construtor concreto.
Alternativa B — ❌ Incorreta
O Prototype cria novos objetos por clonagem de uma instância existente (protótipo). Embora seja útil quando a criação é cara, ele não resolve o problema de construir objetos complexos com processos diferentes; a clonagem replica a mesma representação, não gerando variações a partir de um mesmo processo.
Alternativa C — ❌ Incorreta
O Factory Method define uma interface para criar um objeto, mas delega a decisão de qual classe instanciar para subclasses. Ele é adequado quando uma classe não pode antecipar a classe de objetos que deve criar. No entanto, ele não separa o processo de construção em etapas nem permite a criação de diferentes representações de um mesmo objeto complexo de forma tão flexível quanto o Builder. Para relatórios com etapas de construção distintas (cabeçalho, corpo, rodapé), o Builder é mais apropriado.
Alternativa D — ❌ Incorreta
O Singleton garante uma única instância de uma classe e fornece acesso global a ela. Não se aplica à construção de objetos complexos com diferentes representações; seu foco é controle de instância, não criação variada.
Alternativa E — ❌ Incorreta
Object Pool (não é um padrão GoF original, mas um padrão de pool de objetos) mantém um conjunto de objetos prontos para reuso, evitando custo de criação repetida. Ele não possui o conceito de processo de construção variável; apenas reutiliza objetos preexistentes.