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

Question

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 d'implémentation au moment de l'exécution.

Mais je ne sais toujours pas dans quelle situation utiliser une stratégie ou dans quelle situation utiliser un pont.

Answer 1

Sémantique. De wikipedia :

  

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

     

Le couplage entre le contexte et   les stratégies sont plus strictes que les   couplage entre l'abstraction et   la mise en œuvre dans le pont   motif.

Si je comprends bien, vous utilisez le modèle de stratégie lorsque vous abstenez un comportement qui pourrait provenir d'une source externe (par exemple, config pourrait spécifier de charger un module d'extension), 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 motifs pour des raisons légèrement différentes .

Answer 2

Le modèle Bridge est un modèle structurel (COMMENT CONSTRUIRE UN COMPOSANT LOGICIEL?). Le modèle 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 disposez de davantage de moyens pour mener une opération. avec la stratégie, vous pouvez choisir l’algorithme au moment de l’exécution et modifier une stratégie unique sans trop d’effets secondaires au moment de la compilation;
• Pont : vous pouvez fractionner la hiérarchie de l'interface et de la classe et la joindre à une référence abstraite (voir explication )

Answer 3

Stratégie:

• Contexte lié à la stratégie: La classe de contexte (éventuellement abstraite mais pas vraiment une interface! car vous souhaitez encapsuler un comportement spécifique et non la mise en œuvre complète) saurait / contiendrait la référence d'interface de stratégie et la mise en œuvre pour invoquer le comportement de stratégie sur celui-ci.

• L’intention est la possibilité d’échanger 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 le comportement abstrait) ne connaît pas / ne contient pas la référence d'interface d'implémentation

• L'intention est de découpler 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();
  
        }
  
        .............
  
  }
  

Answer 4

Pont : (modèle structurel)

Le modèle de pont dissocie abstraction et implémentation 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 modifications apportées à la mise en œuvre de l'abstraction ne doivent pas affecter l'application de l'appelant
4. Le client doit être isolé des détails de la 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.

Utiliser un modèle de stratégie lorsque:

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

Articles connexes:

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

Exemple concret du modèle de stratégie

Answer 5

Je pensais la même chose, mais récemment, je devais utiliser bridge et me suis rendu compte que bridge utilisait la stratégie et ajoutait une abstraction au contexte afin que vous puissiez ultérieurement apporter davantage de modifications sans changer de client. Lorsque vous utilisez Strategy sans abstraction, la conception n'est pas aussi flexible et peut nécessiter des modifications ultérieures chez le client. Mais lorsque vous utilisez l'ensemble du pont, la conception devient encore plus flexible. Ici, vous pouvez voir comment aller de la stratégie au pont donne plus de flexibilité. Nous supposons également que maintenant " visa " et " maître " ne sont pas seulement disponibles sur les cartes, mais aussi sur les téléphones et les puces; et si nous utilisons un pont, il est beaucoup plus facile d’ajouter ce support.

Answer 6

Types de modèle de conception

Les modèles
• Behavioral: décrivent la manière dont les classes ou les objets interagissent et répartissent les responsabilités
Les liens
• Structural: traitent de la composition de classes ou d'objets.
• Creational: les motifs sont préoccupés par le processus de création d'objet.

Bridge (Structural)

  

Découplez une abstraction de son implémentation afin qu’elle puisse varier.   indépendamment.   

Prenez une télécommande. La télécommande a les 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 résumée de l'implémentation par l'interface d'implémentation.

Cela nous permet de modifier le fonctionnement de la télécommande pour chaque périphérique.

Stratégie (comportemental)

  

Définissez une famille d’algorithmes, encapsulez-les et rendez-les interchangeables.   

En stratégie, si nous examinions le scénario à distance. L’état " " est la totalité de la télécommande que nous échangeons en changeant la référence d'état du contexte. Le " concreteStateA " (Télécommande de télévision) "concreteStateB" (DVD Remote).

Lecture supplémentaire:

• Principes et modèles de conception Java
• Modèles de conception

Answer 7

En ajoutant à la réponse de willcodejavaforfood, ils peuvent être identiques, 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 un pont pour relier les implémentations de deux objets, par exemple un encapsuleur de base de données, et une carte réseau afin que le code client puisse être utilisé avec la même API. Donc, la dénomination dit réellement tout

Answer 8

1. La stratégie est utilisée pour les décisions comportementales, tandis que Bridge est utilisée pour les décisions structurelles.

2. Brigde Pattern sépare les éléments abstraits des détails de la mise en oeuvre, tandis que Stratégie se préoccupe de rendre les algorithmes plus interchangeables.

Modèle de stratégie en langage UML

Modèle Brigde en langage 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")

Modèle 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()

Answer 9

A partir du wiki sur le modèle de stratégie

  

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

     

Le couplage entre le contexte et   les stratégies sont plus strictes que les   couplage entre l'abstraction et   la mise en œuvre dans le pont   motif.

Answer 10

Pour ajouter à ce qui a déjà été dit à propos de la comparaison de modèles (différence d’intention, ...): le modèle de pont est également structuré de manière intentionnelle pour permettre à la hiérarchie des abstractions de varier. Dans des langages tels que C #, cela peut impliquer que vous disposiez d'une base d'abstraction contenant des méthodes virtuelles afin de permettre les variations voulues ne causant pas de problèmes aux consommateurs existants. En dehors de cela, les deux modèles peuvent sembler identiques pour la plupart.

Answer 11

Le modèle de stratégie est utilisé lorsque vous souhaitez appliquer un algorithme ou une stratégie au moment de l'exécution. En tant que catégorie de modèle, 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 la mise en œuvre en introduisant une abstraction plus fine entre eux. 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 permettant d'éviter la création d'un nombre n de classes.

Answer 12

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

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

Maintenant, si A est lui-même abstrait. A et B peuvent varier. Vous utiliseriez un motif de pont.

Answer 13

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 auxquels ils appartiennent tous deux d'un plus grand - afin de 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 bien sûr à OCP, mais ne fait pas nécessairement partie d’un autre concept plus vaste, tel que le modèle Bridge.