Modèle de conception de pont

Bonjour! Nous continuons à comprendre un sujet vaste et très utile : les modèles de conception. Aujourd'hui, nous allons parler de Bridge. Comme d'autres modèles, Bridge sert à résoudre les problèmes courants auxquels un développeur est confronté lors de la conception d'une architecture logicielle. Étudions ses fonctionnalités aujourd'hui et découvrons comment l'utiliser.

Qu'est-ce que le modèle Bridge ?

Le modèle Bridge est un modèle de conception structurelle. Autrement dit, sa tâche principale est de créer une structure complète de classes et d'objets. Bridge résout ce problème en séparant une ou plusieurs classes en hiérarchies distinctes : abstraction et implémentation . Un changement de fonctionnalité dans une hiérarchie n'entraîne pas de changement dans une autre. Tout semble clair, mais en fait cette définition semble très large et ne répond pas à la question principale : « Qu'est-ce que le modèle Bridge ? Je pense que ce sera plus facile à comprendre dans la pratique. Modélisons immédiatement un exemple classique pour le modèle Bridge. Nous avons une classe abstraite Shapequi décrit généralement une figure géométrique :

• Forme.java

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

  Lorsque nous déciderons d'ajouter des formes de triangle et de rectangle, nous hériterons de la classe Shape:

• Rectangle.java :

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

• Triangle.java :

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

Tout semble simple jusqu'à ce que nous introduisions le concept de « couleur ». Autrement dit, chaque figure aura sa propre couleur, dont dépendra la fonctionnalité de la méthode draw(). Pour avoir différentes implémentations de la méthode draw(), nous devons créer une classe pour chaque forme correspondant à une couleur. S'il y a trois couleurs, alors il y a six classes : TriangleBlack, TriangleGreen, TriangleRed, RectangleBlack, RectangleGreenet RectangleRed. Six cours, ce n’est pas si grave. Mais! Si nous devons ajouter une nouvelle forme ou une nouvelle couleur, le nombre de classes augmentera de façon exponentielle. Comment sortir de cette situation ? Stocker les couleurs dans un champ et essayer des options via des conditions n'est pas la meilleure solution. Une bonne solution consiste à afficher la couleur dans une interface distincte . Aussitôt dit, aussitôt fait : créons une interface Coloret trois de ses implémentations - BlackColor, GreenColoretRedColor :

• Couleur.java :

  public interface Color {
     void fillColor();
  }

• BlackColor.java :

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

• CouleurVerte.java

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

• CouleurRouge.java

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

  Ajoutons maintenant un champ de type Colorà la classe Shape- nous recevrons sa valeur dans le constructeur.

• Shape.java :

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

  colorNous utiliserons la variable dans les implémentations Shape. Cela signifie que les formes peuvent désormais utiliser les fonctionnalités de l'interface Color.

• Rectangle.java

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

Voici! Nous pouvons désormais produire différentes couleurs et formes géométriques, même à l'infini, augmentant ainsi le nombre de classes dans la progression arithmétique. Le champ Color colorest un pont qui relie deux hiérarchies de classes distinctes.

Dispositif pont : qu'est-ce que l'abstraction et la mise en œuvre

Jetons un coup d'œil au diagramme de classes qui décrit le modèle Bridge : vous pouvez voir ici deux structures indépendantes qui peuvent être modifiées sans affecter les fonctionnalités de l'autre. Dans notre cas c'est :

• Classe d'abstractionShape ;
• Classes d'abstraction raffinée Triangle,Rectangle ;
• Implémenteur - interfaceColor ;
• Classes ConcreteImplementor BlackColoret GreenColor.RedColor

La classe Shapereprésente une Abstraction - un mécanisme permettant de contrôler la coloration des figures dans différentes couleurs, qui délègue l'implémentation à l'interface Color. Les classes Trianglesont Rectangledes objets réels qui utilisent le mécanisme proposé par la classe Shape. BlackColor, GreenColoret RedColor- des implémentations spécifiques dans la branche Implémentation. On les appelle souvent une plateforme.

Où le modèle Bridge est-il utilisé ?

Un énorme avantage de l’utilisation de ce modèle est que vous pouvez apporter des modifications aux fonctionnalités des classes d’une branche sans briser la logique d’une autre. Cette approche permet également de réduire le couplage des classes de programme. La condition principale pour utiliser les patrons est de « suivre les instructions » : ne les collez nulle part ! En fait, voyons dans quels cas vous devez absolument utiliser Bridge :

1. S'il est nécessaire d'augmenter le nombre d'entités dans deux directions (formes géométriques, couleurs).

2. Si vous souhaitez diviser une grande classe qui ne respecte pas le principe de responsabilité unique en classes plus petites avec des fonctionnalités à profil étroit.

3. S'il est éventuellement nécessaire d'apporter des modifications à la logique de fonctionnement de certaines entités pendant l'exécution du programme.

4. Si nécessaire, cachez l’implémentation aux clients de classe (bibliothèque).

Lorsque vous utilisez un motif à chaque fois, vous devez vous rappeler qu'il ajoute des entités supplémentaires au code - il n'est pas tout à fait logique de l'utiliser dans un projet où il n'y a qu'une seule figure géométrique et une ou deux couleurs possibles.

Avantages et inconvénients du modèle

Comme d’autres modèles, le Bridge présente à la fois des avantages et des inconvénients. Avantages du pont :

1. Améliore l'évolutivité du code - vous pouvez ajouter des fonctionnalités sans craindre de casser quelque chose dans une autre partie du programme.
2. Réduit le nombre de sous-classes - fonctionne lorsqu'il est nécessaire d'augmenter le nombre d'entités dans deux directions (par exemple, le nombre de formes et le nombre de couleurs).
3. Permet de travailler séparément sur deux branches indépendantes d'abstraction et d'implémentation - cela peut être fait par deux développeurs différents sans approfondir les détails du code de chacun.
4. Réduire le couplage des classes - le seul endroit où deux classes sont connectées est le pont (champ Color color).

Inconvénients du pont :

1. En fonction de la situation spécifique et de la structure du projet dans son ensemble, il peut y avoir un impact négatif sur la productivité du programme (par exemple, si davantage d'objets doivent être initialisés).
2. Complique la lisibilité du code en raison de la nécessité de naviguer entre les classes.

Différence avec le modèle de stratégie

Le modèle Bridge est souvent confondu avec un autre modèle de conception, Stratégie. Ils utilisent tous deux la composition (dans l'exemple des formes et des couleurs, nous avons utilisé l'agrégation, mais le motif Bridge peut également utiliser la composition) en déléguant le travail à d'autres objets. Mais il y a une différence entre eux, et elle est énorme. Le modèle Stratégie est un modèle comportemental : il résout des problèmes complètement différents. La stratégie permet l'interchangeabilité des algorithmes, tandis que Bridge sépare l'abstraction de la mise en œuvre pour permettre le choix entre différentes implémentations. Autrement dit, Bridge, contrairement à Strategy, s'applique à des constructions entières ou à des structures hiérarchiques. Le modèle Bridge peut être une bonne arme dans l'arsenal d'un développeur, l'essentiel est de trouver les situations où cela vaut la peine de l'utiliser, ou d'utiliser un autre modèle. Si vous n'êtes pas encore familier avec d'autres modèles, lisez ces documents :

• Singleton
• Usine
• Usine abstraite
• Méthode d'usine
• Procuration
• Adaptateur