web-dev-qa-db-fra.com

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

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 découplent une abstraction de son implémentation et peuvent changer d'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.

design-patternsstrategy-patternbridge
109
Krirk

Sémantique. De wikipedia :

Le diagramme de classe 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 serré 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 extrayez 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 .

62
Kent Boogaart

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 LE 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 )
53
alepuzio

Stratégie:

  • Contexte lié à la stratégie: la classe de contexte (peut-être abstraite mais pas vraiment une interface! Car vous souhaitez encapsuler un comportement spécifique et non l'implémentation entière) connaîtrait/contiendrait la référence d'interface de stratégie et le implémentation = pour invoquer le comportement de stratégie dessus.

  • L'intention est la capacité de changer de comportement lors 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 des abstraits de comportement) ne connaîtrait/ne contiendrait pas la référence d'interface d'implémentation

  • L'intention est de dissocier complètement l'abstraction de la mise en œuvre

    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
MEER

Pont : (Un modèle structurel)

Le modèle de pont dissocie l'abstraction et l'implémentation et permet aux deux de varier indépendamment.

Utilisez ce modèle lorsque:

  1. Les abstractions et 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 la mise en œuvre 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-il différent du modèle d'adaptateur?

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

8
Ravindra babu

Je pensais la même chose, mais récemment j'ai dû utiliser bridge et j'ai réalisé que bridge utilise une stratégie et ajoute de l'abstraction au contexte afin que vous puissiez plus tard apporter plus de changements sans changer le client. Lorsque vous utilisez Strategy sans l'abstraction, la conception n'est pas aussi flexible et peut nécessiter des modifications au client ultérieurement. 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.

Strategy VS Bridge

5
Orhan

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 motifs 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. enter image description here

Prenez une télécommande. La télécommande a les boutons 1-6. Il s'agit de 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 de l'implémenteur.

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

Stratégie (Comportemental)

Définissez une famille d'algorithmes, encapsulez chacun et rendez-les interchangeables. enter image description here

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

Lecture supplémentaire:

3
Daniel

Ajout à 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 avec la même API. Donc la dénomination dit tout

2
Robert Gould

  1. Stratégie Le modèle est utilisé pour les décisions comportementales, tandis que Pont Le modèle est utilisé pour les décisions Décisions structurelles.

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

Modèle de stratégie en UML

Motif Brigde en 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 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()
2
Joan Disho

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

1
Burt

Du wiki sur Stratégie modèle

Le diagramme de classe 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 serré que le couplage entre l'abstraction et l'implémentation dans le pattern Bridge.

1
willcodejavaforfood

Le modèle de stratégie est utilisé lorsque vous souhaitez brancher un algorithme ou une stratégie au moment de l'exécution. La catégorie de motif implique également qu'elle 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 eux. L'abstraction raffinée peut être confondue avec la stratégie d'exécution exécutée (dans le modèle de stratégie). Le modèle de pont traite les aspects structurels en fournissant un mécanisme pour éviter de créer n nombre de classes.

1
Pranav Sharma

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. Ceci est un modèle de stratégie

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

0
Ritesh Tyagi

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

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

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

0
stdout