O que é o padrão de projeto Bridge?

De acordo com as definições do GOF, o padrão Bridge “desacopla uma abstração de sua implementação para que os dois possam variar independentemente”

No Bridge Design Pattern, existem duas camadas.

A primeira camada é a camada de Abstração

e a segunda camada é a Camada de Implementação.

Se eu fizer alguma alteração na Camada de Implementação, isso não afetará a Camada de Abstração.

Da mesma forma, se eu fizer alterações na camada de abstração, isso não afetará a camada de implementação.

Diagrama de classe do padrão de design de ponte:

Conforme mostrado no diagrama anterior, o padrão de projeto da ponte consiste em quatro componentes. Eles são os seguintes:

Implementador :
Esta é uma interface que deve ser implementada por todas as classes de implementação. Essa interface atuará como uma ponte entre a classe de abstração e a classe do implementador.

ConcreteImplementationA / ConcreteImplementaionB :
São classes que implementam o Implementador. Essas classes contêm a implementação concreta de todas as operações.

Abstração :

Esta será uma classe abstrata. que define os métodos para o código do cliente chamar. essa classe abstrata contém uma variável de implementador protegida que contém uma referência ao objeto que executa a implementação.

ConcreteAbstraction / RefinedAbstraction :
são classes herdadas da classe abstrata Abstraction.

Entendendo o Bridge Design Pattern com um exemplo:

Suponha que queremos (produzir e montar) carros novos dos dois tipos a seguir (BMW ou Mercedes).

para isso precisamos de uma oficina para cada tipo para realizar as duas tarefas anteriores (produção e montagem).

Portanto, o diagrama de classes para o nosso exemplo será o seguinte:

Implementação:

Quando precisamos usar o Bridge Design Pattern em aplicações de tempo real?

Precisamos usar o Bridge Design Pattern em aplicações de tempo real, quando:
1- Queremos esconder os detalhes da implementação do cliente.
2- Queremos que a seleção ou troca da implementação seja em tempo de execução e não em tempo de design.
3- Queremos que tanto as classes de abstração quanto as de implementação sejam extensíveis pelas subclasses.
4- Queremos evitar um acoplamento rígido entre uma abstração e sua implementação.
5- As mudanças na implementação de uma abstração não devem ter impacto nos clientes.

Link do código completo no Github:

StructuralDesignPatterns/4-BridgeDP