Padrões de Projeto Estruturais GoF: Adapter, Bridge e Composite

Fala aí, Padawan! Hoje vamos falar sobre três padrões de projeto estruturais do famoso GoF: Adapter, Bridge e Composite. Esses padrões aparecem bastante em concursos de TI porque ajudam a resolver problemas clássicos de organização de código, principalmente quando o sistema começa a crescer e as classes precisam conversar melhor entre si. 

Os padrões de projeto, ou design patterns, são soluções reutilizáveis para problemas recorrentes no desenvolvimento de software. Eles não são códigos prontos para copiar e colar, mas sim modelos de solução. Em concursos públicos, especialmente para cargos de Analista de Sistemas, Desenvolvedor, Auditor de TI e áreas correlatas, é muito comum a banca perguntar a intenção do padrão, quando usar, qual problema ele resolve e quais classes participam da estrutura.

Os padrões do GoF são divididos em três grandes grupos: criacionais, estruturais e comportamentais. Os padrões estruturais tratam da forma como classes e objetos são organizados para formar estruturas maiores. Em outras palavras, Padawan, eles ajudam a encaixar peças de software como se fossem blocos de LEGO, evitando acoplamento excessivo e facilitando manutenção.

Neste artigo, vamos focar em três padrões estruturais muito importantes: Adapter, Bridge e Composite. O Adapter resolve problemas de incompatibilidade entre interfaces. O Bridge separa uma abstração de sua implementação. Já o Composite permite tratar objetos individuais e grupos de objetos de maneira uniforme.

O que são padrões estruturais?

Padrões estruturais são padrões que ajudam a organizar classes e objetos em estruturas mais flexíveis. Quando falamos em “estrutura”, estamos falando da forma como as partes do sistema se conectam. Isso é importante porque sistemas mal estruturados ficam difíceis de manter, testar e evoluir.

Imagine que você tem várias classes funcionando separadamente, mas precisa fazer com que elas trabalhem juntas. Às vezes, uma classe tem o método certo, mas com o nome errado. Às vezes, você quer trocar a implementação sem alterar a regra principal. Em outros casos, você precisa representar uma hierarquia, como pastas e arquivos. É aí que entram os padrões estruturais.

Uma dica de ouro é prestar atenção nas palavras-chave. Se a questão falar em compatibilizar interfaces, pense em Adapter. Se falar em separar abstração de implementação, pense em Bridge. Se falar em hierarquia parte-todo, árvore ou tratar objetos individuais e compostos da mesma forma, pense em Composite.

Adapter: o adaptador Jedi do código

O padrão Adapter permite que classes com interfaces incompatíveis trabalhem juntas. Interface, aqui, pode ser entendida como a forma de comunicação de uma classe: os métodos que ela oferece, os nomes desses métodos e os parâmetros esperados.

Pense em um carregador de tomada. Seu notebook pode ter um plugue em um padrão, mas a tomada da parede pode estar em outro. Você não joga o notebook fora nem quebra a tomada. Você usa um adaptador. No software, a ideia é parecida: quando uma classe já existente não conversa diretamente com o código cliente, criamos um adaptador para fazer essa ponte.

A intenção oficial do Adapter é converter a interface de uma classe em outra interface esperada pelos clientes. Assim, classes que antes não poderiam trabalhar juntas passam a colaborar sem precisar modificar o código original da classe adaptada.

Esse padrão é muito útil quando usamos bibliotecas externas ou sistemas legados. Um sistema legado é um sistema antigo, geralmente ainda importante para a organização, mas que pode ter sido escrito com tecnologias, nomes de métodos ou estruturas diferentes das atuais.

Participantes do Adapter

O padrão Adapter costuma ter quatro participantes principais. O Client é quem usa a interface esperada. O Target é a interface que o cliente conhece. O Adaptee é a classe existente que precisa ser adaptada. O Adapter é a classe que faz a conversão entre o Target e o Adaptee.

No nosso exemplo, Pagamento é o Target, porque é a interface que o sistema espera usar. PagamentoAntigo é o Adaptee, porque é a classe incompatível que já existe. PagamentoAdapter é o Adapter, porque converte a chamada pagar em realizarPagamento. A classe Main representa o Client, pois usa o pagamento sem se preocupar com a adaptação.

Existem dois tipos muito comentados de Adapter: o Adapter de objeto e o Adapter de classe. O Adapter de objeto usa composição, ou seja, guarda uma referência para o objeto adaptado. Foi o que fizemos no exemplo. Já o Adapter de classe usa herança, mas depende da linguagem permitir certas formas de herança, como herança múltipla, o que não é o caso direto do Java para classes.

Bridge: separando abstração e implementação

O padrão Bridge serve para separar uma abstração de sua implementação, permitindo que as duas variem de forma independente. Cuidado, Padawan, não confunda Abstração de OO com abstração citado no padrão Bridge.

Uma abstração é uma ideia geral, aquilo que o cliente enxerga. Por exemplo: “controle remoto”. Já a implementação é como aquilo funciona por baixo. Por exemplo: “TV Samsung”, “TV LG”, “Projetor Epson”. O controle remoto é a abstração; os aparelhos controlados são implementações diferentes.

Sem o Bridge, poderíamos acabar criando várias combinações de classes: ControleRemotoSamsung, ControleRemotoLG, ControleAvancadoSamsung, ControleAvancadoLG e por aí vai. Isso gera explosão de classes, que é quando o número de classes cresce demais por causa das combinações possíveis.

Com o Bridge, separamos as duas dimensões. De um lado ficam os tipos de controle. Do outro, os tipos de aparelho. O controle possui uma referência para o aparelho, e cada lado pode evoluir sem bagunçar o outro.

Diferença entre Adapter, Bridge e Composite

Agora vamos comparar os três padrões, porque banca adora confundir o Padawan distraído. O Adapter é usado quando já existe uma incompatibilidade entre interfaces e você precisa fazer uma classe funcionar com outra. Ele normalmente entra para reaproveitar código existente.

O Bridge é usado quando você quer separar abstração e implementação para que as duas possam variar independentemente. Ele costuma ser uma decisão de projeto mais planejada, usada para evitar muitas combinações de subclasses.

O Composite é usado quando você precisa representar uma estrutura hierárquica em árvore, na qual objetos simples e compostos devem ser tratados de maneira uniforme. Ele aparece muito quando há relação de contêiner e conteúdo, como pasta e arquivo, menu e submenu, organização e departamento.

Uma forma simples de memorizar é esta: Adapter encaixa interfaces incompatíveis; Bridge separa dimensões que variam; Composite monta árvores de objetos.

Quando usar cada padrão?

Use Adapter quando você precisa integrar uma classe existente com uma interface esperada pelo sistema. É muito comum em integração com APIs, bibliotecas externas, sistemas legados e migração de código antigo.

Use Bridge quando há duas ou mais dimensões que podem variar independentemente. Por exemplo, tipos de relatório e formatos de saída. Você pode ter relatório financeiro, relatório acadêmico e relatório administrativo; e pode exportar em PDF, HTML ou CSV. Sem Bridge, as combinações podem explodir.

Use Composite quando você precisa representar estruturas em árvore. Pastas, menus, organogramas e componentes visuais são exemplos clássicos. O ponto central é permitir que o cliente chame os mesmos métodos tanto em objetos simples quanto em grupos de objetos.

Agora é contigo, Padawan: Vamos fazer questões!

CESPE / CEBRASPE – 2024 – CNPQ – Analista em Ciência e Tecnologia Pleno I – Especialidade: Desenvolvimento e Arquitetura de Software

Acerca de padrões de projeto, julgue o item seguinte.  

O padrão adapter da visão GoF permite que uma classe de persistência seja adaptada de acordo com o banco de dados utilizado na aplicação.

Gabarito:
Errado.

Justificativa:

O Adapter serve para permitir que objetos com interfaces incompatíveis trabalhem juntos. Ou seja, ele cria uma classe adaptadora que traduz chamadas de uma interface esperada pelo cliente para a interface de uma classe já existente. Essa é a ideia central do padrão.

A frase da questão sugere outra coisa: variar a implementação da persistência conforme o banco de dados usado, como Oracle, PostgreSQL, MySQL etc. Isso está mais próximo de uma separação entre abstração e implementação, ideia ligada ao Bridge, ou até de Strategy/Factory dependendo da arquitetura adotada. O Bridge, por exemplo, é usado quando se deseja separar uma abstração de suas implementações para que possam variar independentemente.

CESPE / CEBRASPE – 2021 – SERPRO – Analista – Especialização: Desenvolvimento de Sistemas

Acerca de padrões estruturais, julgue o item subsequente.

O propósito do padrão Adapter é separar uma abstração de sua implementação, para que as duas possam variar e ser independentes.

Gabarito:
Errado.

Justificativa:
O item descreve o padrão Bridge, e não o Adapter.

O propósito do Adapter é permitir que classes com interfaces incompatíveis trabalhem juntas. Ele converte a interface de uma classe em outra interface esperada pelo cliente.

Já a frase “separar uma abstração de sua implementação, para que as duas possam variar e ser independentes” corresponde exatamente ao padrão Bridge.

Resumo Jedi para não cair na pegadinha:

Adapter: adapta interfaces incompatíveis.
Bridge: separa abstração de implementação.

Portanto, o item está errado.

FGV – 2023 – AL-MA – Técnico de Gestão Administrativa – Analista de Sistemas

Um padrão de projeto é uma solução geral para um problema que ocorre com frequência dentro de um determinado contexto no projeto de software. O padrão de projeto de software denominado Bridge é um padrão  

Alternativas 

A) estrutural que desacopla uma abstração de sua implementação para que os dois possam variar independentemente. 

B) comportamental destinado a armazenar o estado interno de um objeto em um dado momento para que seja possível retorná-lo a este estado.  

C) de controle de objetos utilizado para garantir que determinada classe só tenha uma única instância e prover um ponto de acesso global a ela. 

D) de criação para instanciar famílias de objetos relacionados por meio de uma única interface e sem que a classe concreta seja especificada. 

E) de interação para prover uma maneira de acessar os elementos de um objeto agregado sequencialmente sem expor sua representação interna. 

Gabarito:
A) estrutural que desacopla uma abstração de sua implementação para que os dois possam variar independentemente.

Justificativa:
O padrão Bridge é um padrão de projeto estrutural do GoF. Sua finalidade é separar uma abstração de sua implementação, permitindo que ambas possam evoluir ou variar de forma independente.

A alternativa A traz exatamente essa definição clássica.

As demais alternativas descrevem outros padrões:

B) descreve o Memento, que salva o estado interno de um objeto.
C) descreve o Singleton, que garante uma única instância.
D) descreve o Abstract Factory, que cria famílias de objetos relacionados.
E) descreve o Iterator, que percorre elementos de um agregado sem expor sua estrutura interna.

Portanto, o padrão Bridge é estrutural e está relacionado ao desacoplamento entre abstração e implementação.

CESPE – 2017 – SEDF – Analista de Gestão Educacional – Tecnologia da Informação

Julgue o item a seguir, a respeito de padrões de projetos.

O padrão de projeto estrutural bridge fornece um objeto substituto, que faz referência a outro objeto.

Gabarito:
Errado.

Justificativa:
O item descreve o padrão Proxy, e não o padrão Bridge.

O Bridge é um padrão estrutural que tem como objetivo separar uma abstração de sua implementação, permitindo que ambas variem independentemente.

Já o Proxy fornece um objeto substituto ou representante que controla o acesso a outro objeto. Esse proxy mantém uma referência ao objeto real e pode adicionar controle de acesso, carregamento sob demanda, cache, logs, entre outras funções.

Resumo Jedi:

Bridge: separa abstração e implementação.
Proxy: fornece um substituto que referencia outro objeto.

Portanto, o item está errado.

CESGRANRIO – 2025 – BANESE – Técnico Bancário III – Desenvolvimento

J é um desenvolvedor de uma empresa e foi incumbido de criar um novo sistema de arquivos. Esse sistema seguirá uma estrutura de árvore com pastas que podem conter arquivos ou outras pastas. Além disso, tanto as pastas como os arquivos compartilharão operações como copiar, mover e excluir.

A partir desse contexto, J lembrou que há um padrão de projeto que poderia ajudá-lo nessa tarefa, que é o  

Alternativas 

A) Adapter

B) Command

C) Composite

D) DAO

E )Singleton

Gabarito:
C) Composite

Justificativa:
O padrão Composite é usado quando precisamos representar uma estrutura em árvore, especialmente em relações do tipo parte-todo.

No enunciado, temos exatamente esse cenário:

• pastas podem conter arquivos; 
• pastas também podem conter outras pastas; 
• arquivos e pastas compartilham operações como copiar, mover e excluir. 

Isso é a cara do Composite, Padawan. Ele permite tratar objetos simples, como arquivos, e objetos compostos, como pastas, de maneira uniforme.

As demais alternativas não se encaixam:

Adapter: adapta interfaces incompatíveis.
Command: encapsula uma solicitação como objeto.
DAO: separa a lógica de acesso a dados.
Singleton: garante uma única instância de uma classe.

Portanto, o padrão adequado para essa estrutura de arquivos em árvore é o Composite.