L'intention de Bridge et Adapter est différente et nous avons besoin des deux modèles séparément.
Modèle de pont:
- C'est un modèle structurel
- L'abstraction et l'implémentation ne sont pas liées au moment de la compilation
- Abstraction et mise en œuvre - les deux peuvent varier sans impact sur le client
- Utilise la composition plutôt que l'héritage.
Utilisez le modèle Bridge lorsque:
- Vous voulez une liaison d'exécution de l'implémentation,
- Vous disposez d'une prolifération de classes résultant d'une interface couplée et de nombreuses implémentations,
- Vous souhaitez partager une implémentation entre plusieurs objets,
- Vous devez mapper des hiérarchies de classes orthogonales.
@ La réponse de John Sonmez montre clairement l'efficacité du modèle de pont pour réduire la hiérarchie des classes.
Vous pouvez vous référer au lien de documentation ci-dessous pour obtenir un meilleur aperçu du modèle de pont avec un exemple de code
Modèle d'adaptateur :
- Il permet à deux interfaces indépendantes de fonctionner ensemble à travers les différents objets, jouant éventuellement le même rôle.
- Il modifie l'interface d'origine.
Principales différences:
- L'adaptateur fait fonctionner les choses après leur conception; Bridge les fait travailler avant qu'ils ne le soient.
- Bridge est conçu à l'avance pour permettre à l' abstraction et à l'implémentation de varier indépendamment . L'adaptateur est mis à niveau pour permettre aux classes indépendantes de travailler ensemble.
- L'intention: Adapter permet à deux interfaces non liées de fonctionner ensemble. Bridge permet à l'abstraction et à l'implémentation de varier indépendamment.
Question SE associée avec diagramme UML et code de travail:
Différence entre le modèle de pont et le modèle d'adaptateur
Articles utiles:
article de modèle de pont de sourcemaking
article de modèle d' adaptateur de sourcemaking
article de modèle de pont journaldev
ÉDITER:
Exemple de modèle de pont réel (selon la suggestion de meta.stackoverflow.com, exemple de site de documentation incorporé dans cet article puisque la documentation va se coucher)
Le modèle de pont dissocie l'abstraction de l'implémentation afin que les deux puissent varier indépendamment. Il a été réalisé avec la composition plutôt que l'héritage.
Modèle de pont UML de Wikipedia:
Vous avez quatre composants dans ce modèle.
Abstraction
: Il définit une interface
RefinedAbstraction
: Il implémente l'abstraction:
Implementor
: Il définit une interface pour l'implémentation
ConcreteImplementor
: Il implémente l'interface de l'implémenteur.
The crux of Bridge pattern :
Deux hiérarchies de classes orthogonales utilisant la composition (et pas d'héritage). La hiérarchie d'abstraction et la hiérarchie d'implémentation peuvent varier indépendamment. La mise en œuvre ne fait jamais référence à l'abstraction. Abstraction contient une interface d'implémentation en tant que membre (via la composition). Cette composition réduit un niveau supplémentaire de hiérarchie d'héritage.
Cas d'utilisation de mots réels:
Permettez à différents véhicules d'avoir les deux versions de système de vitesse manuel et automatique.
Exemple de code:
/* Implementor interface*/
interface Gear{
void handleGear();
}
/* Concrete Implementor - 1 */
class ManualGear implements Gear{
public void handleGear(){
System.out.println("Manual gear");
}
}
/* Concrete Implementor - 2 */
class AutoGear implements Gear{
public void handleGear(){
System.out.println("Auto gear");
}
}
/* Abstraction (abstract class) */
abstract class Vehicle {
Gear gear;
public Vehicle(Gear gear){
this.gear = gear;
}
abstract void addGear();
}
/* RefinedAbstraction - 1*/
class Car extends Vehicle{
public Car(Gear gear){
super(gear);
// initialize various other Car components to make the car
}
public void addGear(){
System.out.print("Car handles ");
gear.handleGear();
}
}
/* RefinedAbstraction - 2 */
class Truck extends Vehicle{
public Truck(Gear gear){
super(gear);
// initialize various other Truck components to make the car
}
public void addGear(){
System.out.print("Truck handles " );
gear.handleGear();
}
}
/* Client program */
public class BridgeDemo {
public static void main(String args[]){
Gear gear = new ManualGear();
Vehicle vehicle = new Car(gear);
vehicle.addGear();
gear = new AutoGear();
vehicle = new Car(gear);
vehicle.addGear();
gear = new ManualGear();
vehicle = new Truck(gear);
vehicle.addGear();
gear = new AutoGear();
vehicle = new Truck(gear);
vehicle.addGear();
}
}
production:
Car handles Manual gear
Car handles Auto gear
Truck handles Manual gear
Truck handles Auto gear
Explication:
Vehicle
est une abstraction.
Car
et Truck
sont deux implémentations concrètes de Vehicle
.
Vehicle
définit une méthode abstraite: addGear()
.
Gear
est l'interface de l'implémenteur
ManualGear
et AutoGear
sont deux implémentations de Gear
Vehicle
contient l' implementor
interface plutôt que l'implémentation de l'interface. Compositon
de l'interface de l'implémenteur est au cœur de ce modèle: il permet à l'abstraction et à l'implémentation de varier indépendamment.
Car
et Truck
définir l'implémentation (abstraction redéfinie) pour l'abstraction addGear()
:: Elle contient Gear
- Soit Manual
soitAuto
Cas d'utilisation du modèle Bridge :
- L'abstraction et l' implémentation peuvent changer indépendamment l'une de l'autre et elles ne sont pas liées au moment de la compilation
- Mappez les hiérarchies orthogonales - une pour l' abstraction et une pour la mise en œuvre .