Padrão de projeto de ponte

Olá! Continuamos a entender um tópico amplo e muito útil – padrões de design. Hoje falaremos sobre Bridge. Assim como outros padrões, o Bridge serve para resolver problemas comuns que um desenvolvedor enfrenta ao projetar uma arquitetura de software. Vamos estudar suas características hoje e descobrir como usá-lo.

Qual é o padrão Bridge?

O padrão Bridge é um padrão de projeto estrutural. Ou seja, sua principal tarefa é criar uma estrutura completa de classes e objetos. O Bridge resolve esse problema dividindo uma ou mais classes em hierarquias separadas – abstração e implementação . Uma alteração na funcionalidade de uma hierarquia não implica alterações em outra. Tudo parece claro, mas na verdade esta definição parece muito ampla e não responde à questão principal: “O que é o padrão Bridge?” Acho que isso será mais fácil para você descobrir na prática. Vamos modelar imediatamente um exemplo clássico para o padrão Bridge. Temos uma classe abstrata Shapeque geralmente descreve uma figura geométrica:

• Forma.java

  public abstract class Shape {
     public abstract void draw();
  }

  Quando decidirmos adicionar formas triangulares e retangulares, herdaremos da classe Shape:

• Retângulo.java:

  public class Rectangle extends Shape {
     @Override
     public void draw() {
         System.out.println("Drawing rectangle");
     }
  }

• Triângulo.java:

  public class Triangle extends Shape {
     @Override
     public void draw() {
         System.out.println("Drawing triangle");
     }
  }

Tudo parece simples até introduzirmos o conceito de “cor”. Ou seja, cada figura terá sua cor própria, da qual dependerá a funcionalidade do método draw(). Para termos diferentes implementações do método draw(), precisamos criar uma classe para cada forma correspondente a uma cor. Se houver três cores, então haverá seis classes: TriangleBlack, TriangleGreen, TriangleRed, RectangleBlack, RectangleGreene RectangleRed. Seis aulas não é grande coisa. Mas! Se precisarmos adicionar uma nova forma ou cor, o número de classes crescerá exponencialmente. Como sair desta situação? Armazenar cores em um campo e testar opções através de condicionais não é a melhor solução. Uma boa solução é exibir as cores em uma interface separada . Mal dito e feito: vamos criar uma interface Colore três de suas implementações BlackColor- GreenColore RedColor:

• Cor.java:

  public interface Color {
     void fillColor();
  }

• PretoColor.java:

  public class BlackColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in black color");
     }
  }

• GreenColor.java

  public class GreenColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in green color");
     }
  }

• RedColor.java

  public class RedColor implements Color {
     @Override
     public void fillColor() {
         System.out.println("Filling in red color");
     }
  }

  Agora vamos adicionar um campo de tipo Colorà classe Shape- receberemos seu valor no construtor.

• Forma.java:

  public abstract class Shape {
     protected Color color;
  
     public Shape(Color color) {
         this.color = color;
     }
  
     public abstract void draw();
  }

  colorUsaremos a variável nas implementações Shape. Isso significa que as formas agora podem usar a funcionalidade da interface Color.

• Retângulo.java

  public class Rectangle extends Shape {
  
     public Rectangle(Color color) {
         super(color);
     }
  
     @Override
     public void draw() {
         System.out.println("Drawing rectangle");
         color.fillColor();
     }
  }

Aqui você vai! Agora podemos produzir diferentes cores e formas geométricas até mesmo ad infinitum, aumentando o número de classes na progressão aritmética. O campo Color coloré uma ponte que interconecta duas hierarquias de classes separadas.

Dispositivo Bridge: o que é abstração e implementação

Vamos dar uma olhada no diagrama de classes que descreve o padrão Bridge: Aqui você pode ver duas estruturas independentes que podem ser modificadas sem afetar a funcionalidade uma da outra. No nosso caso é:

• Abstração - aula Shape;
• Abstração Refinada - classes Triangle, Rectangle;
• Implementador-interface Color;
• Classes ConcreteImplementor BlackColore GreenColor.RedColor

A classe Shaperepresenta uma Abstração - mecanismo de controle da coloração de formas em cores diferentes, que delega a Implementação à interface Color. Classes Trianglesão Rectangleobjetos reais que utilizam o mecanismo oferecido pela classe Shape. BlackColore GreenColor- RedColorimplementações específicas no ramo Implementação. Eles são frequentemente chamados de plataforma.

Onde o padrão Bridge é usado?

Uma grande vantagem de usar esse padrão é que você pode fazer alterações na funcionalidade das classes de um branch sem quebrar a lógica de outro. Esta abordagem também ajuda a reduzir o acoplamento de classes de programas. A principal condição para usar os moldes é “seguir as instruções”: não cole em lugar nenhum! Na verdade, vamos descobrir em quais casos você definitivamente precisa usar o Bridge:

1. Se for necessário expandir o número de entidades em duas direções (formas geométricas, cores).

2. Se você quiser dividir uma classe grande que não atende ao princípio de responsabilidade única em classes menores com funcionalidade de perfil restrito.

3. Caso haja a possível necessidade de realizar alterações na lógica de funcionamento de determinadas entidades durante a execução do programa.

4. Se necessário, oculte a implementação dos clientes da classe (biblioteca).

Ao usar um padrão a cada vez, você precisa lembrar que ele adiciona entidades adicionais ao código - não é totalmente lógico usá-lo em um projeto onde há apenas uma figura geométrica e uma ou duas cores possíveis.

Prós e contras do padrão

Como outros padrões, o Bridge tem vantagens e desvantagens. Benefícios da ponte:

1. Melhora a escalabilidade do código - você pode adicionar funcionalidades sem medo de quebrar algo em outra parte do programa.
2. Reduz o número de subclasses - funciona quando é necessário expandir o número de entidades em duas direções (por exemplo, o número de formas e o número de cores).
3. Torna possível trabalhar separadamente em dois ramos independentes de Abstração e Implementação - isso pode ser feito por dois desenvolvedores diferentes sem se aprofundar nos detalhes do código um do outro.
4. Reduzindo o acoplamento de classes - o único local onde duas classes estão conectadas é a ponte (campo Color color).

Desvantagens da ponte:

1. Dependendo da situação específica e da estrutura do projeto como um todo, pode haver um impacto negativo na produtividade do programa (por exemplo, se for necessário inicializar mais objetos).
2. Complica a legibilidade do código devido à necessidade de navegar entre as classes.

Diferença do padrão Estratégia

O padrão Bridge é frequentemente confundido com outro padrão de design, Strategy. Ambos usam composição (no exemplo de formas e cores usamos agregação, mas o padrão Bridge também pode usar composição) delegando o trabalho a outros objetos. Mas há uma diferença entre eles e é enorme. O padrão Estratégia é um padrão comportamental: resolve problemas completamente diferentes. A estratégia permite que os algoritmos sejam intercambiáveis, enquanto o Bridge separa a abstração da implementação para permitir a escolha entre diferentes implementações. Ou seja, Bridge, diferentemente de Strategy, aplica-se a construções inteiras ou estruturas hierárquicas. O padrão Bridge pode ser uma boa arma no arsenal de um desenvolvedor, o principal é encontrar aquelas situações em que vale a pena usá-lo, ou usar algum outro padrão. Se você ainda não está familiarizado com outros modelos, leia estes materiais:

• Solteiro
• Fábrica
• Fábrica Abstrata
• Método de Fábrica
• Procurador
• Adaptador