Domanda

Ho provato a leggere molti articoli su dofactory , wikipedia e molti siti. Non ho idea delle differenze tra il modello del ponte e il modello della strategia.

So che entrambi dissociano un'astrazione dalla sua implementazione e posso cambiarla in fase di esecuzione.

Ma non so ancora in quale situazione dovrei usare la strategia o in quale situazione dovrei usare bridge.

È stato utile?

Soluzione

Semantica. Da wikipedia :

  

Il diagramma delle classi UML per la strategia   il modello è lo stesso del diagramma per   il modello Bridge. Tuttavia, questi due   i modelli di progettazione non sono gli stessi in   il loro intento. Mentre la strategia   modello è pensato per il comportamento, il   Il modello del ponte è pensato per la struttura.

     

L'accoppiamento tra il contesto e   le strategie sono più rigorose di   accoppiamento tra l'astrazione e   l'implementazione nel Bridge   modello.

A quanto ho capito, stai usando il modello di strategia durante l'astrazione di comportamenti che potrebbero essere forniti da una fonte esterna (ad es. config potrebbe specificare di caricare alcuni assembly plugin), e stai usando il modello bridge quando usi gli stessi costrutti per rendere il tuo codice un po 'più ordinato. Il codice effettivo sarà molto simile: stai solo applicando i pattern per motivi leggermente diversi .

Altri suggerimenti

Il modello Bridge è un modello strutturale (COME COSTRUISCI UN COMPONENTE SOFTWARE?). Il modello di strategia è un modello dinamico (COME VUOI ESEGUIRE UN COMPORTAMENTO NEL SOFTWARE?).

La sintassi è simile ma gli obiettivi sono diversi:

  • Strategia : hai più modi per eseguire un'operazione; con la strategia, puoi scegliere l'algoritmo in fase di esecuzione e puoi modificare una singola strategia senza molti effetti collaterali in fase di compilazione;
  • Bridge : puoi dividere la gerarchia di interfaccia e classe, unirla ad un riferimento astratto (vedi spiegazione )

Strategia:

  • Contesto legato alla strategia: la classe di contesto (possibilmente astratta ma non proprio un'interfaccia! poiché desideri incapsulare un comportamento specifico e non l'intera implementazione) saprebbe / contenga il riferimento dell'interfaccia di strategia e l'implementazione per invocare il comportamento strategico su di esso.
  • L'intento è la capacità di scambiare il comportamento in fase di esecuzione

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

Ponte

  • Astrazione non legata all'implementazione: l'interfaccia di astrazione (o classe astratta con la maggior parte dell'abstract comportamentale) non saprebbe / conterrebbe il riferimento dell'interfaccia di implementazione
  • L'intento è quello di disaccoppiare completamente l'astrazione dall'implementazione

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

Bridge : (un modello strutturale)

Il modello a ponte disaccoppia l'astrazione e l'implementazione e consente a entrambi di variare in modo indipendente.

Usa questo modello quando:

  1. Astrazioni e implementazioni non sono state decise al momento della compilazione
  2. Astrazioni e implementazioni dovrebbero essere modificate in modo indipendente
  3. I cambiamenti nell'implementazione dell'astrazione non dovrebbero influenzare l'applicazione del chiamante
  4. Il client deve essere isolato dai dettagli di implementazione.

Strategia: (modello comportamentale)

I modelli di strategia ti consentono di passare da più algoritmi a una famiglia di algoritmi in fase di esecuzione.

Usa il modello di strategia quando:

  1. Sono necessarie più versioni di algoritmi
  2. Il comportamento della classe deve essere modificato in modo dinamico in fase di esecuzione
  3. Evita le dichiarazioni condizionali

Articoli correlati:

Quando usi il modello Bridge? In cosa differisce dal modello dell'adattatore?

Esempio reale del modello di strategia

Stavo pensando lo stesso, ma recentemente ho dovuto usare bridge e ho capito che bridge sta usando la strategia e aggiungendo astrazione al contesto in modo che in seguito sia possibile apportare ulteriori modifiche senza cambiare il client. Quando si utilizza la strategia senza l'astrazione, il design non è così flessibile e potrebbe richiedere modifiche al client in un secondo momento. Ma quando si utilizza l'intero ponte, il design diventa ancora più flessibile. Qui puoi vedere come passare da Strategia a Bridge offre maggiore flessibilità. Supponiamo inoltre che ora "visto". e "master" non sono disponibili solo su carte ma anche su telefoni e chip; e se usiamo bridge è molto più facile aggiungere quel supporto.

 Strategia VS Bridge

Tipi di pattern di progettazione

  • Comportamentali: i modelli caratterizzano il modo in cui le classi o gli oggetti interagiscono e distribuiscono la responsabilità
  • I modelli
  • Strutturali: riguardano la composizione di classi o oggetti.
  • Creazionale: i motivi sono preoccupati per il processo di creazione dell'oggetto.

Bridge (strutturale)

  

Disaccoppia un'astrazione dalla sua implementazione in modo che ognuna possa variare.   indipendentemente.    inserisci qui la descrizione dell'immagine

Prendi un telecomando. Il telecomando ha i pulsanti 1-6. Questa è la classe concreta nel diagramma sopra. Ogni pulsante funzionerà in modo diverso a seconda che il telecomando sia utilizzato per una TV o un DVD. La funzionalità di ciascun pulsante viene sottratta all'implementazione dall'interfaccia dell'attuatore.

Questo ci consente di cambiare il funzionamento del telecomando per ciascun dispositivo.

Strategia (Behavioral)

  

Definisci una famiglia di algoritmi, incapsula ciascuno e rendili intercambiabili.    inserisci qui la descrizione dell'immagine

In strategia, se stessimo guardando lo scenario remoto. Lo stato "quot" è l'intero telecomando che sostituiamo cambiando il riferimento di stato del contesto. Il "concreteStateA" (Telecomando TV) "concreteStateB" (Telecomando DVD).

Letture aggiuntive:

Aggiungendo alla risposta di willcodejavaforfood, possono essere gli stessi, in fase di implementazione. Tuttavia, si utilizza la strategia per scambiare strategie come la strategia di ordinamento, mentre si utilizza bridge per collegare le implementazioni di due oggetti, ad esempio un wrapper di database e una scheda di rete, in modo che il codice client possa utilizzare sia la stessa API. Quindi la denominazione in realtà dice tutto

  1. Strategia Il pattern viene utilizzato per le decisioni comportamentali, mentre il Bridge Pattern viene utilizzato per le decisioni strutturali.

  2. Brigde Pattern separa gli elementi astratti dai dettagli di implementazione, mentre Strategia Pattern si preoccupa di rendere gli algoritmi più intercambiabili.

Modello di strategia in UML

Modello di Brigde in UML

Schema di strategia in 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")

Brigde Pattern in 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()

Dal wiki su Strategia pattern

  

Il diagramma delle classi UML per la strategia   il modello è lo stesso del diagramma per   il modello Bridge. Tuttavia, questi due   i modelli di progettazione non sono gli stessi in   il loro intento. Mentre la strategia   modello è pensato per il comportamento, il   Il modello del ponte è pensato per la struttura.

     

L'accoppiamento tra il contesto e   le strategie sono più rigorose di   accoppiamento tra l'astrazione e   l'implementazione nel Bridge   modello.

Solo per aggiungere ciò che è già stato detto sul confronto dei modelli (differenza di intenti, ...): il modello Bridge è anche intenzionalmente strutturato per consentire al lato gerarchico di astrazione di variare. In linguaggi come C # questo potrebbe significare che hai una base di astrazione che contiene metodi virtuali come un modo per consentire variazioni previste che non causano problemi ai consumatori esistenti. A parte questo, i due motivi potrebbero apparire identici per la maggior parte.

Il modello di strategia viene utilizzato quando si desidera collegare l'algoritmo o la strategia in fase di esecuzione. Poiché la categoria del modello implica anche che si occupa del comportamento degli oggetti. D'altra parte il ponte è il modello strutturale e si occupa della gerarchia strutturale degli oggetti. Disaccoppia l'astrazione dall'attuazione introducendo una raffinata astrazione tra di loro. L'astrazione raffinata può essere confusa con la strategia di runtime inserita (nel modello di strategia). Il modello a ponte si occupa degli aspetti strutturali fornendo un meccanismo per evitare di creare n numero di classi.

Per il modello di strategia varia solo l'implementazione.

Supponiamo che la classe A stia usando la classe B che ha più implementazioni disponibili. Quindi in quel caso B sarebbe astratto con l'implementazione effettiva fornita in fase di esecuzione. Questo è il modello di strategia

Ora se A stesso è astratto. Sia A che B possono variare. Utilizzeresti il ??modello Bridge.

Penso che ci sia una leggera differenza tra loro nel contesto in cui vengono utilizzati.

Uso il modello Bridge per separare i concetti ortogonali a cui entrambi appartengono a uno più grande - per farli variare in modo indipendente. Di solito comporta più astrazioni.

IMO, il modello di strategia è più semplice o più piatto. Serve sicuramente all'OCP, ma non necessariamente fa parte di un altro concetto più ampio come il modello Bridge.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top