Question

Quelle est la différence entre les modèles Bridge et Adapter?

Était-ce utile?

La solution

  

"Adapter permet aux choses de fonctionner après leur conception; Le pont les rend   travailler avant qu'ils soient. [GoF, p219] "

En réalité, le modèle Adaptateur est utile lorsque vous avez un code existant, qu'il soit tiers ou interne, mais que vous ne pouvez pas le contrôler, ni qu'il ne soit pas modifiable pour correspondre à l'interface dont vous avez besoin. c'est à. Par exemple, nous avons un SuperWeaponsArray qui peut contrôler une gamme étendue de périphériques Doomsday.

public class SuperWeaponsArray {
  /*...*/

  public void destroyWorld() {
    for (Weapon w : armedWeapons) {
      w.fire();
    }
  }
}

Génial. Sauf que nous nous rendons compte que nous avons dans notre arsenal un dispositif nucléaire qui précède de loin la conversion à l'interface Weapon. Mais nous aimerions vraiment que cela fonctionne ici ... alors, que faisons-nous ... coincons-le!

NukeWeaponsAdaptor - basé sur notre classe Nuke, mais exportant l'interface Weapon. Doux, maintenant nous pouvons sûrement détruire le monde. Cela peut sembler un peu ridicule, mais cela fait fonctionner les choses.

Le modèle Pont est quelque chose que vous implémentez dès le départ. Si vous savez que vous avez deux hiérarchies orthogonales, il offre un moyen de découpler l'interface et la mise en œuvre de manière à ne pas obtenir un nombre fou de classes. Disons que vous avez:

Types d’objets fichier MemoryMappedFile et DirectReadFile. Supposons que vous souhaitiez pouvoir lire des fichiers provenant de différentes sources (peut-être des implémentations Linux ou Windows, etc.). Bridge vous aide à éviter de vous retrouver avec:

MemoryMappedWindowsFile MemoryMappedLinuxFile DirectReadWindowsFile DirectReadLinuxFile

Autres conseils

http://fr.wikipedia.org/wiki/Adapter_pattern

Le modèle d'adaptateur consiste davantage à faire en sorte que votre code existant fonctionne avec un système ou une interface plus récents.

Si vous avez un ensemble d'API de service Web standard que vous souhaitez proposer à l'interface d'extensibilité existante d'une autre application, vous pouvez envisager d'écrire un ensemble d'adaptateurs à cette fin. Notez qu'il existe une zone grise et qu'il s'agit davantage de la façon technique dont vous définissez le modèle, car d'autres modèles, comme la façade, sont similaires.

http://fr.wikipedia.org/wiki/Bridge_pattern

Le modèle Bridge vous permettra éventuellement d’avoir des implémentations alternatives d’un algorithme ou d’un système.

Bien qu’il ne s’agisse pas d’un exemple classique de modèle Bridge, imaginez si vous disposiez de quelques implémentations d’un magasin de données: l’un est efficace en termes d’espace, l’autre en termes de performances brutes… application ou cadre.

Pour ce qui est de votre question, "où puis-je utiliser quel modèle," La réponse est: partout où cela convient à votre projet! Envisagez peut-être de proposer une modification afin de guider la discussion sur les domaines dans lesquels vous estimez avoir besoin d'utiliser l'un ou l'autre.

Adaptateur:

  1. C’est un schéma structurel
  2. Il est utile de travailler avec deux interfaces incompatibles

Diagramme UML: de dofactory article:

 entrez la description de l'image ici

Cible : définit l'interface spécifique au domaine utilisée par le client.

Adaptateur : adapte l'interface Adaptee à l'interface cible.

Adaptee : définit une interface existante à adapter.

Client : collabore avec des objets conformes à l'interface cible.

Exemple:

Carré et Rectangle sont deux formes différentes et obtenir la zone () de chacune d’elles nécessite des méthodes différentes. Cependant, Square travaille toujours sur l'interface Rectangle avec la conversion de certaines propriétés.

public class AdapterDemo{
    public static void main(String args[]){
        SquareArea s = new SquareArea(4);
        System.out.println("Square area :"+s.getArea());
    }
}

class RectangleArea {
    public int getArea(int length, int width){
        return length * width;
    }
}

class SquareArea extends RectangleArea {

    int length;
    public SquareArea(int length){
        this.length = length;
    }
    public int getArea(){
        return getArea(length,length);
    }
}

Pont:

  1. C'est un modèle structurel
  2. il sépare une abstraction de son implémentation et les deux peuvent varier indépendamment
  3. Cela est possible car la composition a été utilisée à la place de l'héritage

EDIT: (selon la suggestion de @quasoft)

Vous avez quatre composants dans ce modèle.

  1. Abstraction : définit une interface

  2. RefinedAbstraction : Il implémente l'abstraction:

  3. Implementor : définit une interface pour la mise en oeuvre

  4. ConcreteImplementor : Il implémente l'interface Implementor.

Extrait de code:

Gear gear = new ManualGear();
Vehicle vehicle = new Car(gear);
vehicle.addGear();

gear = new AutoGear();
vehicle = new Car(gear);
vehicle.addGear();

Article lié:

Quand utilisez-vous le motif de pont? En quoi est-il différent du modèle d’adaptateur?

Principales différences: tirées de l'article de la création de source de production

.
  1. L'adaptateur fait en sorte que les choses fonctionnent après leur conception. Bridge les fait travailler avant d’être.
  2. Bridge est conçu dès le départ pour laisser l’abstraction et la mise en œuvre varier de façon indépendante. L'adaptateur est installé ultérieurement pour que les classes non apparentées travaillent ensemble.

Ce message existe depuis assez longtemps. Cependant, il est important de comprendre qu'une façade ressemble à un adaptateur, mais ce n'est pas tout à fait la même chose. Un adaptateur "s'adapte" une classe existante à une classe client généralement non compatible. Supposons que votre application utilise un ancien système de flux de travail en tant que client. Votre entreprise pourrait éventuellement remplacer le système de flux de travail par un nouveau système "incompatible". un (en termes d'interfaces). Dans la plupart des cas, vous pouvez utiliser le modèle d'adaptateur et écrire du code qui appelle en réalité les interfaces du nouveau moteur de flux de travail. Un pont est généralement utilisé d'une manière différente. Si vous avez un système qui doit fonctionner avec différents systèmes de fichiers (disque local, NFS, etc.), vous pouvez utiliser le modèle de pont et créer une couche d’abstraction pour fonctionner avec tous vos systèmes de fichiers. Ce serait fondamentalement un cas d'utilisation simple pour le modèle de pont. La façade et l'adaptateur partagent certaines propriétés, mais les façades sont généralement utilisées pour simplifier une interface / classe existante . Au début des EJB, il n'y avait pas d'appel local pour les EJB. Les développeurs ont toujours obtenu le talon, l'ont réduit et l'ont appelé "pseudo-distant". Cela entraînait souvent des problèmes de performances (surtout quand on appelait vraiment par le fil). Les développeurs expérimentés utiliseraient le motif de façade pour fournir une interface très grossière au client. Cette façade effectuerait alors à son tour plusieurs appels à différentes méthodes plus détaillées. Globalement, cela a considérablement réduit le nombre d’appels de méthodes requis et amélioré les performances.

Supposons que vous ayez une classe Shape abstraite avec une fonctionnalité de dessin (générique / abstraite) et un cercle qui implémente la forme. Le modèle de pont est simplement une approche d'abstraction bidirectionnelle pour découpler la mise en œuvre (dessin dans Circle) et la fonctionnalité générique / abstraite (dessin dans la classe Shape).

Qu'est-ce que cela signifie vraiment? À première vue, cela ressemble à quelque chose que vous faites déjà (par inversion de dépendance). Donc, ne vous inquiétez pas d'avoir une base de code moins évolutive ou plus modulaire. Mais c'est une philosophie un peu plus profonde derrière cela.

De ma compréhension, le besoin de modèle d'utilisation peut apparaître lorsque je dois ajouter de nouvelles classes étroitement liées au système actuel (comme RedCircle ou GreenCircle) et qui ne diffèrent que par une seule fonctionnalité (comme la couleur). Et je vais avoir besoin du modèle Bridge, en particulier si les classes système existantes (Circle ou Shape) doivent être fréquemment modifiées et si vous ne souhaitez pas que les classes nouvellement ajoutées soient affectées par ces modifications. C’est pourquoi la fonctionnalité de dessin générique est abstraite dans une nouvelle interface, ce qui vous permet de modifier le comportement du dessin indépendamment de Shape ou de Circle.

Le pont est amélioré Adaptateur. Bridge comprend un adaptateur et ajoute une flexibilité supplémentaire. Voici comment les éléments de la réponse de Ravindra font le lien entre les motifs:

      Adapter  |    Bridge
    -----------|---------------
    Target     | Abstraction
    -----------|---------------
               | RefinedAbstraction
               |
               |   This element is Bridge specific. If there is a group of 
               |   implementations that share the same logic, the logic can be placed here.
               |   For example, all cars split into two large groups: manual and auto. 
               |   So, there will be two RefinedAbstraction classes.
    -----------|--------------- 
    Adapter    | Implementor
    -----------|---------------
    Adaptee    | ConcreteImplementor
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top