Quand utilisez-vous le modèle de pont? En quoi est-ce différent du modèle d'adaptateur?

Quelqu'un at-il déjà utilisé le modèle de pont dans une application du monde réel? Si oui, comment l'avez-vous utilisé? Est-ce moi, ou est-ce juste le modèle d'adaptateur avec une petite injection de dépendance jetée dans le mélange? Mérite-t-il vraiment son propre modèle?

Un exemple classique du modèle de pont est utilisé dans la définition de formes dans un environnement d'interface utilisateur (voir l'entrée Wikipedia du modèle de pont ). Le modèle Bridge est un composite des modèles de modèle et de stratégie .

Il s'agit d'une vue commune de certains aspects du modèle d'adaptateur dans le modèle de pont. Cependant, pour citer cet article :

À première vue, le modèle Bridge ressemble beaucoup au modèle Adapter dans la mesure où une classe est utilisée pour convertir un type d'interface en un autre. Cependant, l'intention du modèle d'adaptateur est de donner à une ou plusieurs interfaces de classes la même apparence que celle d'une classe particulière. Le modèle Bridge est conçu pour séparer l'interface d'une classe de son implémentation afin que vous puissiez modifier ou remplacer l'implémentation sans changer le code client.

Il y a une combinaison des réponses de Federico et de John .

Quand:

                   ----Shape---
                  /            \
         Rectangle              Circle
        /         \            /      \
BlueRectangle  RedRectangle BlueCircle RedCircle

Refactoriser en:

          ----Shape---                        Color
         /            \                       /   \
Rectangle(Color)   Circle(Color)           Blue   Red

Le modèle Bridge est une application du vieux conseil, "préférez la composition à l'héritage". Cela devient pratique lorsque vous devez sous-classer différents moments de manière orthogonale les uns par rapport aux autres. Disons que vous devez implémenter une hiérarchie de formes colorées. Vous ne sous-classeriez pas Shape avec Rectangle et Circle, puis sous-classeriez Rectangle avec RedRectangle, BlueRectangle et GreenRectangle et la même chose pour Circle, n'est-ce pas? Vous préféreriez dire que chaque forme a une couleur et implémenter une hiérarchie de couleurs, et c'est le modèle de pont. Eh bien, je n'implémenterais pas une "hiérarchie de couleurs", mais vous voyez l'idée ...

Quand:

        A
     /     \
    Aa      Ab
   / \     /  \
 Aa1 Aa2  Ab1 Ab2

Refactoriser en:

     A         N
  /     \     / \
Aa(N) Ab(N)  1   2

L'adaptateur et le pont sont certainement liés, et la distinction est subtile. Il est probable que certaines personnes qui pensent utiliser l'un de ces modèles utilisent en fait l'autre modèle.

L'explication que j'ai vue est que Adapter est utilisé lorsque vous essayez d'unifier les interfaces de certaines classes incompatibles qui existent déjà . L'adaptateur fonctionne comme une sorte de traducteur d'implémentations qui pourraient être considérées comme héritées .

Alors que le modèle Bridge est utilisé pour le code qui est plus susceptible d'être greenfield. Vous concevez le Bridge pour fournir une interface abstraite pour une implémentation qui doit varier, mais vous définissez également l'interface de ces classes d'implémentation.

Les pilotes de périphériques sont un exemple souvent cité de Bridge, mais je dirais que c'est un Bridge si vous définissez la spécification d'interface pour les fournisseurs de périphériques, mais c'est un adaptateur si vous prenez des pilotes de périphérique existants et créez une classe wrapper pour fournir une interface unifiée.

Donc, au niveau du code, les deux modèles sont très similaires. Sur le plan commercial, ils sont différents.

Voir aussi http://c2.com/cgi/wiki?BridgePattern

D'après mon expérience, Bridge est un modèle assez souvent récurrent, car c'est la solution chaque fois qu'il y a deux dimensions orthogonales dans le domaine . Par exemple, les formes et les méthodes de dessin, les comportements et les plates-formes, les formats de fichiers et les sérialiseurs, etc.

Et un conseil: pensez toujours aux modèles de conception du point de vue conceptuel , pas du point de vue de la mise en œuvre. Du bon point de vue, Bridge ne peut pas être confondu avec Adapter, car ils résolvent un problème différent, et la composition est supérieure à l'héritage non pas à cause d'elle-même, mais parce qu'elle permet de traiter séparément les problèmes orthogonaux.

L'intention de Bridge et Adapter est différente et nous avons besoin des deux modèles séparément.

Modèle de pont:

1. C'est un modèle structurel
2. L'abstraction et l'implémentation ne sont pas liées au moment de la compilation
3. Abstraction et mise en œuvre - les deux peuvent varier sans impact sur le client
4. Utilise la composition plutôt que l'héritage.

Utilisez le modèle Bridge lorsque:

1. Vous voulez une liaison d'exécution de l'implémentation,
2. Vous disposez d'une prolifération de classes résultant d'une interface couplée et de nombreuses implémentations,
3. Vous souhaitez partager une implémentation entre plusieurs objets,
4. 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 :

1. Il permet à deux interfaces indépendantes de fonctionner ensemble à travers les différents objets, jouant éventuellement le même rôle.
2. Il modifie l'interface d'origine.

Principales différences:

1. L'adaptateur fait fonctionner les choses après leur conception; Bridge les fait travailler avant qu'ils ne le soient.
2. 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.
3. 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:

1. Vehicle est une abstraction.
2. Caret Trucksont deux implémentations concrètes de Vehicle.
3. Vehicledéfinit une méthode abstraite: addGear().
4. Gear est l'interface de l'implémenteur
5. ManualGearet AutoGearsont deux implémentations de Gear
6. Vehiclecontient l' implementorinterface plutôt que l'implémentation de l'interface. Compositonde 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.
7. Caret Truckdéfinir l'implémentation (abstraction redéfinie) pour l'abstraction addGear():: Elle contient Gear- Soit ManualsoitAuto

Cas d'utilisation du modèle Bridge :

1. 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
2. Mappez les hiérarchies orthogonales - une pour l' abstraction et une pour la mise en œuvre .

J'ai utilisé le modèle de pont au travail. Je programme en C ++, où il est souvent appelé l'idiome PIMPL (pointeur vers l'implémentation). Cela ressemble à ceci:

class A
{
public: 
  void foo()
  {
    pImpl->foo();
  }
private:
  Aimpl *pImpl;
};

class Aimpl
{
public:
  void foo();
  void bar();
};  

Dans cet exemple, class Acontient l'interface et class Aimplcontient l'implémentation.

Une utilisation de ce modèle consiste à exposer uniquement certains des membres publics de la classe d'implémentation, mais pas d'autres. Dans l'exemple, seul Aimpl::foo()peut être appelé via l'interface publique de A, mais pasAimpl::bar()

Un autre avantage est que vous pouvez définir Aimpldans un fichier d'en-tête séparé qui n'a pas besoin d'être inclus par les utilisateurs de A. Tout ce que vous avez à faire est d'utiliser une déclaration Aimplavant de Adéfinir avant et de déplacer les définitions de toutes les fonctions membres référençant pImpldans le fichier .cpp. Cela vous permet de garder l'en- Aimpltête privé et de réduire le temps de compilation.

Pour mettre un exemple de forme dans le code:

#include<iostream>
#include<string>
#include<cstdlib>

using namespace std;

class IColor
{
public:
    virtual string Color() = 0;
};

class RedColor: public IColor
{
public:
    string Color()
    {
        return "of Red Color";
    }
};

class BlueColor: public IColor
{
public:
    string Color()
    {
        return "of Blue Color";
    }
};


class IShape
{
public:
virtual string Draw() = 0;
};

class Circle: public IShape
{
        IColor* impl;
    public:
        Circle(IColor *obj):impl(obj){}
        string Draw()
        {
            return "Drawn a Circle "+ impl->Color();
        }
};

class Square: public IShape
{
        IColor* impl;
    public:
        Square(IColor *obj):impl(obj){}
        string Draw()
        {
        return "Drawn a Square "+ impl->Color();;
        }
};

int main()
{
IColor* red = new RedColor();
IColor* blue = new BlueColor();

IShape* sq = new Square(red);
IShape* cr = new Circle(blue);

cout<<"\n"<<sq->Draw();
cout<<"\n"<<cr->Draw();

delete red;
delete blue;
return 1;
}

La sortie est:

Drawn a Square of Red Color
Drawn a Circle of Blue Color

Notez la facilité avec laquelle de nouvelles couleurs et formes peuvent être ajoutées au système sans conduire à une explosion des sous-classes en raison des permutations.

pour moi, je pense que c'est un mécanisme où vous pouvez échanger des interfaces. Dans le monde réel, vous pourriez avoir une classe qui peut utiliser plus d'une interface, Bridge vous permet d'échanger.

Vous travaillez pour une compagnie d'assurance où vous développez une application de workflow qui gère différents types de tâches: comptabilité, contrat, sinistres. C'est l'abstraction. Côté implémentation, vous devez être capable de créer des tâches à partir de différentes sources: email, fax, e-messagerie.

Vous commencez votre conception avec ces classes:

public class Task {...}
public class AccountingTask : Task {...}
public class ContractTask : Task {...}
public class ClaimTask : Task {...}

Désormais, chaque source devant être gérée de manière spécifique, vous décidez de spécialiser chaque type de tâche:

public class EmailAccountingTask : AccountingTask {...}
public class FaxAccountingTask : AccountingTask {...}
public class EmessagingAccountingTask : AccountingTask {...}

public class EmailContractTask : ContractTask {...}
public class FaxContractTask : ContractTask {...}
public class EmessagingContractTask : ContractTask {...}

public class EmailClaimTask : ClaimTask {...}
public class FaxClaimTask : ClaimTask {...}
public class EmessagingClaimTask : ClaimTask {...}

Vous vous retrouvez avec 13 cours. L'ajout d'un type de tâche ou d'un type source devient difficile. L'utilisation du modèle de pont produit quelque chose de plus facile à maintenir en découplant la tâche (l'abstraction) de la source (ce qui est un problème d'implémentation):

// Source
public class Source {
   public string GetSender();
   public string GetMessage();
   public string GetContractReference();
   (...)
}

public class EmailSource : Source {...}
public class FaxSource : Source {...}
public class EmessagingSource : Source {...}

// Task
public class Task {
   public Task(Source source);
   (...)
}
public class AccountingTask : Task {...}
public class ContractTask : Task {...}
public class ClaimTask : Task {...}

L'ajout d'un type de tâche ou d'une source est désormais beaucoup plus simple.

Remarque: la plupart des développeurs ne créeraient pas la hiérarchie des 13 classes à l'avance pour gérer ce problème. Cependant, dans la vraie vie, vous ne connaissez peut-être pas à l'avance le nombre de types de sources et de tâches; si vous n'avez qu'une seule source et deux types de tâches, vous ne dissocierez probablement pas la tâche de la source. Ensuite, la complexité globale augmente à mesure que de nouvelles sources et types de tâches sont ajoutés. À un moment donné, vous refactoriserez et, le plus souvent, vous vous retrouverez avec une solution de type pont.

Bridge design pattern we can easily understand helping of service and dao layer.

Dao layer -> create common interface for dao layer ->
public interface Dao<T>{
void save(T t);
}
public class AccountDao<Account> implement Dao<Account>{
public void save(Account){
}
}
public LoginDao<Login> implement Dao<Login>{
public void save(Login){
}
}
Service Layer ->
1) interface
public interface BasicService<T>{
    void save(T t);
}
concrete  implementation of service -
Account service -
public class AccountService<Account> implement BasicService<Account>{
 private Dao<Account> accountDao;
 public AccountService(AccountDao dao){
   this.accountDao=dao;
   }
public void save(Account){
   accountDao.save(Account);
 }
}
login service- 
public class LoginService<Login> implement BasicService<Login>{
 private Dao<Login> loginDao;
 public AccountService(LoginDao dao){
   this.loginDao=dao;
   }
public void save(Login){
   loginDao.save(login);
 }
}

public class BridgePattenDemo{
public static void main(String[] str){
BasicService<Account> aService=new AccountService(new AccountDao<Account>());
Account ac=new Account();
aService.save(ac);
}
}
}