Padrão Bridge
- objetivo: desacoplar uma abstração de sua implementação de forma que as duas coisas possam variar independentemente.
- Quando queremos ter várias implementações de uma abstração, geralmente criamos uma classe abstrata para definir a abstração e subclasses concretas para definir as implementações.
- Mas isso cola as duas coisas permanentemente, não permitindo que elas evoluam independentemente.
- Pense
numa interface gráfica que deve ser portada para diferentes
plataformas. P.ex., 3 tipos de janelas e 4 plataformas. O código do
cliente precisaria lidar com tipo específico de plataforma onde a
interface seria renderizada.
- Com o padrão Bridge, temos
duas hierarquias de classes independentes: a da abstração e a da
implementação. As implementações concretas da abstração fazem uso das
operações abstratas da implementação.
- Mudanças na implementação
não afetam os clientes da abstração, ou seja, não precisamos recompilar o
cliente quando as implementações mudam.
- Segundo o Joe Yoder, é um dos padrões de projeto menos usados.
- Se você conhecer um exemplo interessante onde este padrão é útil, mande para mim.
- Um muito bom sobre o padrão Bridge
- Exemplo interessante em Java (vamos olhar o código na aula)
- A descrição original do GoF
- Uma explicação mais leve do refactoring guru
Última atualização: quinta-feira, 24 nov. 2022, 10:01