Différence entre le modèle de pont et le modèle d’adaptateur

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

    “L’adaptateur rend les choses fonctionnelles après leur conception; Bridge les fait fonctionner avant qu’elles ne le soient. [GoF, p219]”

    Effectivement, le modèle d’adaptateur est utile lorsque vous avez du code existant, qu’il soit tiers ou interne, mais que vous ne contrôlez pas ou que vous ne pouvez pas changer l’interface pour laquelle vous en avez besoin. Par exemple, nous avons un SuperWeaponsArray qui peut contrôler un large éventail de périphériques Doodday.

    public class SuperWeaponsArray { /*...*/ public void destroyWorld() { for (Weapon w : armedWeapons) { w.fire(); } } } 

    Génial. Sauf que nous sums conscients que notre arsenal comporte un dispositif nucléaire qui précède largement la conversion à l’interface Arme. Mais nous aimerions vraiment que ça marche ici … alors qu’est-ce qu’on fait?

    NukeWeaponsAdaptor – basé sur notre classe Nuke, mais exportant l’interface Weapon. Doux, maintenant nous pouvons sûrement détruire le monde. Cela semble un peu compliqué, mais ça fait marcher les choses.


    Le pattern Bridge est quelque chose que vous implémentez en amont – si vous savez que vous avez deux hiérarchies orthogonales, cela permet de découpler l’interface et l’implémentation de manière à ne pas avoir un nombre insensé de classes. Disons que vous avez:

    Types d’objects de fichiers MemoryMappedFile et DirectReadFile. Supposons que vous souhaitiez pouvoir lire des fichiers provenant de diverses sources (implémentations Linux vs Windows, etc.). Bridge vous aide à éviter de vous retrouver avec:

    MemoryMappedWindowsFile MemoryMappedLinuxFile DirectReadWindowsFile DirectReadLinuxFile

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

    La configuration de l’adaptateur concerne davantage l’utilisation de votre code existant avec un système ou une interface plus récent.

    Si vous souhaitez proposer un ensemble d’API de service Web d’entreprise à l’interface d’extensibilité existante d’une autre application, vous pouvez envisager d’écrire un ensemble d’adaptateurs pour ce faire. Notez qu’il ya une zone grise et que c’est plus sur la façon dont vous définissez techniquement le motif, car d’autres motifs comme la façade sont similaires.

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

    Le pattern Bridge va vous permettre d’avoir des implémentations alternatives d’un algorithme ou d’un système.

    Bien que ce ne soit pas un exemple classique de modèle de pont, imaginez si vous aviez quelques implémentations d’un magasin de données: l’une est efficace dans l’espace, l’autre est efficace dans les performances brutes… .

    En termes de votre question, “où puis-je utiliser quel modèle”, la réponse est, où que cela soit logique pour votre projet! Pensez peut-être à proposer une mise au sharepoint clarification pour guider la discussion sur les domaines dans lesquels vous pensez devoir utiliser l’un ou l’autre.

    Ce post existe depuis un certain temps. Cependant, il est important de comprendre qu’une façade ressemble un peu à un adaptateur, mais ce n’est pas la même chose. Un adaptateur “adapte” une classe existante à une classe client généralement non compatible. Disons que vous avez un ancien système de workflow que votre application utilise en tant que client. Votre entreprise pourrait éventuellement remplacer le système de workflow par un nouveau système “incompatible” (en termes d’interfaces). Dans la plupart des cas, vous pouvez utiliser le modèle d’adaptateur et écrire le code qui appelle en réalité les interfaces du nouveau moteur de workflow. Un pont est généralement utilisé de 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 travailler 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’appels locaux pour les EJB. Les développeurs ont toujours obtenu le talon, l’ont réduit et l’ont appelé “pseudo-à distance”. Cela a souvent causé des problèmes de performance (surtout quand on a vraiment appelé par-dessus 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 ferait alors à son tour plusieurs appels vers différentes méthodes plus fines. Dans l’ensemble, cela a considérablement réduit le nombre d’appels de méthodes requirejs et les performances accrues.

    Adaptateur:

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

    Diagramme UML: extrait de l’ article dofactory :

    entrer la description de l'image ici

    Cible : définit l’interface spécifique au domaine que le client utilise.

    Adapter : adapte l’interface Adaptee à l’interface cible.

    Adaptee : définit une interface existante à adapter.

    Client : collabore avec des objects conformes à l’interface cible.

    Exemple:

    Carré et Rectangle sont deux formes différentes et obtenir une zone () de chacun d’eux nécessite des méthodes différentes. Mais encore Square travaille sur l’interface Rectangle avec la conversion de certaines propriétés.

     public class AdapterDemo{ public static void main(Ssortingng 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 motif structurel
    2. il dissocie une abstraction de sa mise en œuvre et les deux peuvent varier indépendamment
    3. C’est possible parce que la composition a été utilisée à la place de l’inheritance

    EDIT: (selon la suggestion de @quasoft)

    Vous avez quatre composants dans ce modèle.

    1. Abstraction : définit une interface

    2. RefinedAbstraction : implémente l’abstraction:

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

    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 similaire:

    Quand utilisez-vous le Pattern Bridge? En quoi est-ce différent du modèle d’adaptateur?

    Différences clés: de l’article sur la fabrication de pain

    1. L’adaptateur rend les choses fonctionnelles après leur conception; Bridge les fait fonctionner avant qu’ils ne le soient.
    2. Bridge est conçu pour permettre à l’abstraction et à l’implémentation de varier de manière indépendante. L’adaptateur est installé ultérieurement pour que les classes non liées fonctionnent ensemble.

    Supposons que vous ayez une classe de forme abstraite avec une fonctionnalité de dessin (générique / abstraite) et un cercle qui implémente la forme. Bridge pattern est simplement une approche d’abstraction bidirectionnelle pour découpler l’implémentation (dessin dans Circle) et les fonctionnalités génériques / abstraites (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, pas de souci d’avoir une base de code moins rigide ou plus modulaire. Mais c’est une philosophie un peu plus profonde.

    D’après ce que j’ai compris, le besoin d’un modèle d’utilisation peut apparaître lorsque j’ai besoin d’append 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 d’un modèle de pont, en particulier si les classes système existantes (Cercle ou Forme) doivent être fréquemment modifiées et que vous ne voulez pas que les classes nouvellement ajoutées soient affectées par ces modifications. C’est pourquoi la fonctionnalité de dessin générique est extraite dans une nouvelle interface afin que vous puissiez modifier le comportement de dessin indépendamment de Shape ou Circle.

    Bridge est amélioré Adaptateur. Bridge inclut un adaptateur et ajoute une flexibilité supplémentaire. Voici comment les éléments de la réponse de Ravindra établissent une correspondance entre les modèles:

      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