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 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.

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 .

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 )

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();
  
        }
  
        .............
  
  }
  

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.

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

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.

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.

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:

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

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()

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

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.

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.

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.

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.

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.