Salut! Nous continuons maintenant à nous plonger dans un sujet très utile et très important : les modèles de conception. Aujourd'hui, parlons du modèle de pont. Comme d'autres modèles, le modèle de pont sert à résoudre les problèmes typiques rencontrés par un développeur lors de la conception d'une architecture logicielle. Aujourd'hui, étudions les caractéristiques de ce modèle et découvrons comment l'utiliser.
Quel est le modèle de pont?
Le modèle de pont est un modèle de conception structurelle. En d'autres termes, sa tâche principale est de créer une structure à part entière à partir de classes et d'objets. Pour ce faire, un pont divise 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 l'autre. C'est très bien, mais cette définition est très large et ne répond pas à la question la plus importante : "Qu'est-ce que le modèle de pont ?" Je pense qu'il vous sera plus facile de comprendre son application pratique. Alors tout de suite, créons un scénario classique pour le modèle de pont. Nous avons une Shapeclasse abstraite, qui représente une figure géométrique générique :
Forme.java
public abstract class Shape {
public abstract void draw();
}
Lorsque nous décidons d'ajouter des formes comme des triangles et des rectangles, nous leur ferons hériter de la Shapeclasse :
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'au moment où nous introduisons le concept de couleur. Autrement dit, chaque forme aura sa propre couleur et la fonctionnalité de la draw()méthode dépendra de cette couleur. Pour avoir différentes implémentations de la draw()méthode, nous devons créer une classe pour chaque combinaison forme-couleur. Si nous avons trois couleurs, alors nous avons besoin de six classes : TriangleBlack, TriangleGreen, TriangleRed, RectangleBlack, RectangleGreenet RectangleRed. Six classes n'est pas un si gros problème. Mais! Si nous devons ajouter une nouvelle forme ou couleur, le nombre de classes augmente de façon exponentielle. Comment sortir de cette situation ? Stocker la couleur dans un champ et énumérer toutes les options à l'aide d'instructions conditionnelles n'est pas la meilleure solution. Une bonne solution consiste à déplacer la couleur vers une interface séparée. Aussitôt dit, aussitôt fait : créons une Colorinterface avec trois implémentations : BlackColor, GreenColoret RedColor:
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");
}
}
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");
}
}
Maintenant, nous ajoutons un Colorchamp à la Shapeclasse. Nous obtiendrons sa valeur dans le constructeur.
Forme.java :
public abstract class Shape {
protected Color color;
public Shape(Color color) {
this.color = color;
}
public abstract void draw();
}
Nous utiliserons la colorvariable dans Shapeles implémentations. Cela signifie que les formes peuvent désormais utiliser les fonctionnalités de l' Colorinterface.
Rectangle.java
public class Rectangle extends Shape {
public Rectangle(Color color) {
super(color);
}
@Override
public void draw() {
System.out.println("Drawing rectangle");
color.fillColor();
}
}
Ta-da ! Maintenant, nous pouvons créer différentes couleurs et formes à l'infini, et le nombre de classes n'augmentera que de manière linéaire. Le Color colorchamp est un pont qui relie deux hiérarchies de classes distinctes.
Comment construire un pont : abstraction et mise en œuvre
Regardons un diagramme de classes qui décrit le modèle de pont : Ici, vous pouvez voir deux structures indépendantes qui peuvent être modifiées sans affecter les fonctionnalités de l'autre. Dans notre cas:
L'abstraction est la Shapeclasse
RefinedAbstraction est la classe TriangleetRectangle
L'implémenteur est l' Colorinterface
ConcreteImplementor correspond aux classes BlackColor, GreenColoret RedColor.
La Shapeclasse est une abstraction — un mécanisme de gestion du remplissage des formes avec différentes couleurs, qui délègue à l' Colorinterface (Implementor). Les classes Triangleet Rectanglesont des classes concrètes qui utilisent le mécanisme mis à disposition par la Shapeclasse. BlackColor, GreenColoret RedColorsont des implémentations concrètes dans la hiérarchie d'implémentation.
Où utiliser le motif de pont
Un énorme avantage de l'utilisation de ce modèle est que vous pouvez apporter des modifications aux classes fonctionnelles dans une hiérarchie sans briser la logique de l'autre. De plus, cette approche permet de réduire le couplage entre les classes. La principale exigence lors de l'utilisation de ce modèle est de "suivre les instructions" - n'en ignorez aucune ! À cette fin, découvrons les situations dans lesquelles vous devez absolument utiliser le modèle de pont :
Si vous avez besoin d'augmenter le nombre d'entités basées sur des combinaisons de deux concepts (par exemple, les formes et les couleurs).
Si vous souhaitez diviser une grande classe qui ne respecte pas le principe de responsabilité unique en classes plus petites qui ont des fonctionnalités étroites.
S'il est nécessaire d'apporter des modifications à la logique de certaines entités pendant l'exécution du programme.
S'il est nécessaire de cacher une implémentation aux clients de la classe ou de la bibliothèque.
Lorsque vous utilisez ce modèle, rappelez-vous toujours qu'il ajoute des entités supplémentaires à votre code - cela n'a peut-être pas de sens de l'utiliser dans un projet où il n'y a qu'une seule forme et une ou deux couleurs possibles.
Avantages et inconvénients du modèle
Comme d'autres modèles, un pont présente à la fois des avantages et des inconvénients. Avantages du modèle de pont :
Cela améliore l'évolutivité du code - vous pouvez ajouter des fonctionnalités sans craindre de casser quelque chose dans une autre partie du programme.
Il réduit le nombre de sous-classes alors que le nombre d'entités serait autrement basé sur des combinaisons de deux concepts (par exemple, formes et couleurs).
Il permet de travailler séparément sur deux hiérarchies distinctes - Abstraction et Implémentation. Deux développeurs différents peuvent apporter des modifications sans se plonger dans les détails du code de l'autre.
Il réduit le couplage entre les classes — le seul endroit où les deux classes sont couplées est le pont (c'est-à-dire le Color colorchamp).
Inconvénients du modèle de pont :
Selon la situation spécifique et la structure globale d'un projet, cela pourrait avoir un impact négatif sur les performances d'un programme (par exemple, si vous devez initialiser plus d'objets).
Cela rend le code moins lisible en raison de la nécessité de basculer entre les deux classes.
Différence avec le modèle de stratégie
Le modèle de pont est souvent confondu avec un autre modèle de conception - la stratégie. Ils utilisent tous les deux la composition (bien que nous ayons utilisé l'agrégation dans l'exemple avec des figures et des couleurs, le motif Bridge peut également utiliser la composition), déléguant le travail à d'autres objets. Mais il y a une différence entre eux, et elle est énorme. Le pattern stratégie est un pattern comportemental : il résout des problèmes complètement différents. La stratégie permet d'interchanger les algorithmes, tandis que le pont sépare une abstraction des implémentations afin de choisir entre différentes implémentations. En d'autres termes, contrairement à une stratégie, un pont s'applique à des entités entières ou à des structures hiérarchiques. Le modèle de pont peut être une bonne arme dans l'arsenal d'un développeur. L'essentiel est d'identifier les situations où il vaut la peine de l'utiliser et de reconnaître quand un autre modèle est approprié.
Artem is a programmer-switcher. His first profession was rehabilitation specialist. Previously, he helped people restore their hea ...
[Lisez la bio complète]
Ici, vous pouvez voir deux structures indépendantes qui peuvent être modifiées sans affecter les fonctionnalités de l'autre. Dans notre cas:
GO TO FULL VERSION