Quelle est la différence entre le modèle de pont et le modèle de stratégie?


114

J'ai essayé de lire de nombreux articles sur dofactory , wikipedia et de nombreux sites. Je n'ai aucune idée des différences entre le modèle de pont et le modèle de stratégie.

Je sais que les deux dissocient une abstraction de son implémentation et peuvent changer l'implémentation au moment de l'exécution.

Mais je ne sais toujours pas dans quelle situation je devrais utiliser la stratégie ou dans quelle situation je devrais utiliser le bridge.

Réponses:


66

Sémantique. De wikipedia :

Le diagramme de classes UML pour le modèle de stratégie est le même que le diagramme pour le modèle de pont. Cependant, ces deux modèles de conception ne sont pas les mêmes dans leur intention. Alors que le modèle de stratégie est destiné au comportement, le modèle de pont est destiné à la structure.

Le couplage entre le contexte et les stratégies est plus étroit que le couplage entre l'abstraction et l'implémentation dans le pattern Bridge.

Si je comprends bien, vous utilisez le modèle de stratégie lorsque vous faites abstraction d'un comportement qui pourrait être fourni à partir d'une source externe (par exemple, config pourrait spécifier de charger un assemblage de plug-in), et vous utilisez le modèle de pont lorsque vous utilisez les mêmes constructions pour rendre votre code un peu plus net. Le code réel sera très similaire - vous appliquez simplement les modèles pour des raisons légèrement différentes .


3
alors puis-je dire que j'utilise le modèle de stratégie pour être capable d'abstraire le comportement tout en rendant le code plus net comme dans le modèle de pont ... ou, j'utilise le modèle de pont pour rendre le code plus net et aussi parce qu'il me permet à un comportement abstrait comme dans le modèle de stratégie? et aurais-je raison?
user20358

1
La différence entre les deux réside uniquement dans leur intention. Donc, je suppose que nous pourrions dire que, parce que les deux utilisent la même idée et offrent la même flexibilité, les deux modèles sont fonctionnellement identiques.
Elz le

3
L'UML de Bridge est assez différent dans mon exemplaire du livre GoF. Cet outil est capable de distinguer Bridge de Stratégie.
Fuhrmanator

1
Wikipédia est souvent une référence terrible. À juste titre, cette désinformation a été supprimée de la page. en.wikipedia.org/w/…
Fuhrmanator

2
La façon dont je comprends, c'est que la même technique est utilisée pour abstraire une implémentation (stratégie) ou pour abstraire une interface (pont). La stratégie échange les comportements, le pont échange les interfaces (cela permet finalement aux implémentations avec de telles interfaces d'être permutées). En d'autres termes, Bridge crée une interface standardisée d'un côté et connecte des implémentations avec différentes interfaces de l'autre.
Nikaas

55

Le modèle Bridge est un modèle structurel (COMMENT CONSTRUIRE UN COMPOSANT LOGICIEL?). Le modèle de stratégie est un modèle dynamique (COMMENT VOULEZ-VOUS EXÉCUTER UN COMPORTEMENT DANS UN LOGICIEL?).

La syntaxe est similaire mais les objectifs sont différents:

  • Stratégie : vous avez plus de façons de faire une opération; avec la stratégie, vous pouvez choisir l'algorithme au moment de l'exécution et vous pouvez modifier une seule stratégie sans beaucoup d'effets secondaires au moment de la compilation;
  • Bridge : vous pouvez diviser la hiérarchie de l'interface et de la classe, la joindre avec une référence abstraite (voir explication )

3
Donc, si la syntaxe est similaire, aurais-je raison de dire que j'utilise l'un ou l'autre de ces modèles pour exécuter un comportement logiciel d'une manière particulière et aussi parce que je veux construire le composant de cette manière pour qu'il soit également soigné?
user20358

11

Stratégie:

  • Contexte lié à la stratégie: La classe de contexte (éventuellement abstraite mais pas vraiment une interface! Comme vous souhaitez encapsuler un comportement spécifique et non l'implémentation entière) connaîtrait / contiendrait la référence de l'interface de stratégie et l' implémentation pour invoquer le comportement de la stratégie sur il.
  • L'intention est la capacité à permuter le comportement au moment de l'exécution

    class Context {
    
         IStrategy strategyReference;
    
         void strategicBehaviour() {
    
            strategyReference.behave();
         }
    
    }
    

Pont

  • Abstraction non liée à l'implémentation: l'interface d'abstraction (ou la classe abstraite avec la plupart de l'abstrait de comportement) ne connaîtrait pas / ne contiendrait pas la référence d'interface d'implémentation
  • L'intention est de découpler complètement l'abstraction de l'implémentation

    interface IAbstraction {
    
        void behaviour1();
    
        .....
    
    }
    
    interface IImplementation {
    
         void behave1();
    
         void behave2();
    
         .....
    
    }
    
    class ConcreteAbstraction1 implements IAbstraction {
    
          IImplementation implmentReference;
    
          ConcreteAbstraction1() {
    
               implmentReference = new ImplementationA() // Some implementation
    
          }
    
          void behaviour1() {
    
                implmentReference.behave1();
    
          }
    
          .............
    
    }
    
    class ConcreteAbstraction2 implements IAbstraction {
    
          IImplementation implmentReference;
    
          ConcreteAbstraction1() {
    
               implmentReference = new ImplementationB() // Some Other implementation
    
          }
    
          void behaviour1() {
    
                implmentReference.behave2();
    
          }
    
          .............
    
    }
    

10

Je pensais la même chose, mais récemment, j'ai dû utiliser bridge et j'ai réalisé que bridge utilise la stratégie et ajoute de l'abstraction au contexte afin que vous puissiez plus tard faire plus de changements sans changer le client. Lors de l'utilisation de Strategy sans l'abstraction, la conception n'est pas aussi flexible et peut nécessiter des modifications ultérieures du client. Mais lors de l'utilisation de l'ensemble du pont, la conception devient encore plus flexible. Ici, vous pouvez voir comment passer de la stratégie au pont donne plus de flexibilité. Nous supposons également que maintenant "visa" et "master" ne sont pas seulement disponibles sur les cartes mais aussi sur les téléphones et les puces; et si nous utilisons bridge, il est beaucoup plus facile d'ajouter ce support.

Stratégie VS Bridge


9

Pont : (Un modèle structurel)

Le modèle de pont dissocie l'abstraction et la mise en œuvre et permet aux deux de varier indépendamment.

Utilisez ce modèle lorsque:

  1. Les abstractions et les implémentations n'ont pas été décidées au moment de la compilation
  2. Les abstractions et les implémentations doivent être modifiées indépendamment
  3. Les changements dans l'implémentation de l'abstraction ne devraient pas affecter l'application de l'appelant
  4. Le client doit être isolé des détails de mise en œuvre.

Stratégie: (modèle comportemental)

Les modèles de stratégie vous permettent de basculer entre plusieurs algorithmes d'une famille d'algorithmes au moment de l'exécution.

Utilisez le modèle de stratégie lorsque:

  1. Plusieurs versions d'algorithmes sont requises
  2. Le comportement de la classe doit être modifié dynamiquement au moment de l'exécution
  3. Évitez les instructions conditionnelles

Articles Similaires:

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

Exemple du monde réel du modèle de stratégie


4

Types de modèles de conception

  • Comportemental: les modèles caractérisent la manière dont les classes ou les objets interagissent et répartissent la responsabilité
  • Structurel: les motifs traitent de la composition des classes ou des objets.
  • Créatif: les modèles sont concernés par le processus de création d'objet.

Pont (structurel)

Découpez une abstraction de son implémentation afin que chacune puisse varier. indépendamment. entrez la description de l'image ici

Prenez une télécommande. La télécommande a des boutons 1-6. C'est la classe concrète dans le diagramme ci-dessus. Chaque bouton fonctionnera différemment selon que la télécommande est utilisée pour un téléviseur ou un DVD. La fonctionnalité de chaque bouton est extraite de l'implémentation par l'interface d'implémentation.

Cela nous permet de modifier le fonctionnement de la télécommande pour chaque appareil.

Stratégie (comportementale)

Définissez une famille d'algorithmes, encapsulez chacun d'eux et rendez-les interchangeables. entrez la description de l'image ici

En stratégie, si nous regardions le scénario distant. L '"état" est la totalité de la télécommande que nous échangeons en changeant la référence d'état du contexte. Le "concretStateA" (télécommande TV) "concretStateB" (télécommande DVD).

Lecture supplémentaire:


3
  1. Le modèle de stratégie est utilisé pour les décisions comportementales, tandis que le modèle de pont est utilisé pour les décisions structurelles.

  2. Brigde Pattern sépare les éléments abstraits des détails d'implémentation, tandis que Strategy Pattern vise à rendre les algorithmes plus interchangeables.

Modèle de stratégie dans UML

Motif de Brigde dans UML

Modèle de stratégie dans Swift:

protocol PrintStrategy {
   func print(_ string: String) -> String
}

class Printer {
   let strategy: PrintStrategy

   init(strategy: PrintStrategy) {
      self.strategy = strategy
    }

  func print(_ string: String) -> String {
     return self.strategy.print(string)
  }
}

class UpperCaseStrategy: PrintStrategy {
    internal func print(_ string: String) -> String {
        return string.uppercased()
    }
}

class LowerCaseStrategy: PrintStrategy {
    internal func print(_ string: String) -> String {
        return string.lowercased()
    }
}

var lower = Printer(strategy: LowerCaseStrategy())
lower.print("I love Software Patterns")

var upper = Printer(strategy: UpperCaseStrategy())
upper.print("I love Software Patterns")

Motif de Brigde dans Swift:

protocol Appliance {
   func run()
}

protocol Switch {
   let appliance: Appliance {get set}
   func turnOn()
}

class RemoteControl: Switch {
   var appliance: Appliance

   init(appliance: Appliance) {
       self.appliance = appliance
   }

   internal func turnOn() {
      appliance.run()
   }
}

class TV: Appliance {
   internal func run() {
      print("TV is ON")
   }
}

class Stereo: Appliance {
   internal func run() {
      print("Stereo is ON")
   }
}

var tvRemote = RemoteControl.init(appliance: TV())
tvRemote.turnOn()

var stereoRemote = RemoteControl.init(appliance: Stereo())
stereoRemote.turnOn()

comment se fait-il que seul le modèle de stratégie soit plus «interchangeable». Puisque nous codons pour interfacer, pas pour implémenter, nous pouvons échanger les implémentations en stratégie, ou en pont, comme vous l'avez démontré dans votre exemple de code, échanger Stereoavec TVet le code fonctionne.
denis631

2

Ajoutant à la réponse de willcodejavaforfood, ils peuvent être les mêmes, dans la mise en œuvre. Cependant, vous utilisez une stratégie pour échanger des stratégies telles que la stratégie de tri, tandis que vous utilisez bridge pour relier les implémentations de deux objets, par exemple un wrapper de base de données et une carte réseau afin que le code client puisse utiliser l'un ou l'autre fonctionnant avec la même API. Donc le nom dit tout


1

Depuis le wiki sur le modèle de stratégie

Le diagramme de classes UML pour le modèle de stratégie est le même que le diagramme pour le modèle de pont. Cependant, ces deux modèles de conception ne sont pas les mêmes dans leur intention. Alors que le modèle de stratégie est destiné au comportement, le modèle de pont est destiné à la structure.

Le couplage entre le contexte et les stratégies est plus étroit que le couplage entre l'abstraction et l'implémentation dans le pattern Bridge.


Pourriez-vous élaborer la dernière phrase?
gstackoverflow

1

Juste pour ajouter à ce qui a déjà été dit à propos de la comparaison de modèles (différence d'intention, ...): le modèle Bridge est également intentionnellement structuré pour permettre au côté hiérarchie d'abstraction de varier. Dans des langages comme C #, cela pourrait impliquer que vous ayez une base d'abstraction contenant des méthodes virtuelles afin d'autoriser les variations voulues qui ne causent pas de problèmes aux consommateurs existants. À part cela, les deux modèles peuvent sembler identiques pour la plupart.


1

Le modèle de stratégie est utilisé lorsque vous souhaitez connecter un algorithme ou une stratégie au moment de l'exécution. En tant que catégorie de motif, cela implique également qu'il traite du comportement des objets. D'autre part, le pont est un modèle structurel et traite de la hiérarchie structurelle des objets. Il dissocie l'abstraction de l'implémentation en introduisant une abstraction raffinée entre elles. L'abstraction raffinée peut être confondue avec la stratégie d'exécution branchée (modèle In Strategy). Le modèle de pont traite les aspects structurels en fournissant un mécanisme pour éviter de créer un nombre n de classes.


1

Pour le modèle de stratégie, seule la mise en œuvre varie.

Supposons que la classe A utilise la classe B qui a plusieurs implémentations disponibles. Donc, dans ce cas, B serait abstrait avec une implémentation réelle fournie au moment de l'exécution. C'est un modèle de stratégie

Maintenant, si A lui-même est abstrait. Les deux A et B peuvent varier. Vous utiliseriez le modèle Bridge.


0

Je pense qu'il y a une légère différence entre eux dans le contexte dans lequel ils sont utilisés.

J'utilise le modèle Bridge pour séparer les concepts orthogonaux dont ils appartiennent tous les deux à un plus grand - pour les laisser varier indépendamment. Cela implique généralement plusieurs abstractions.

OMI, le modèle de stratégie est plus simple ou plus plat. Cela sert à coup sûr à OCP mais ne fait pas nécessairement partie d'un autre concept plus grand comme le modèle Bridge.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.