Pergunta

Eu tentei ler muitos artigos sobre dofactory , wikipedia e muitos sites. Eu não tenho idéia sobre as diferenças entre o padrão de ponte e o padrão de estratégia.

Eu sei que ambos dissociar uma abstração de sua implementação e pode mudar implementação em tempo de execução.

Mas eu ainda não sei em que situação eu deveria usar estratégia ou em que situação eu deveria usar ponte.

Foi útil?

Solução

A semântica. De wikipedia :

O diagrama de classes UML para a Estratégia padrão é o mesmo que o diagrama para o padrão Bridge. No entanto, estes dois padrões de projeto não são os mesmos em sua intenção. Embora a Estratégia padrão é para o comportamento, a Ponte padrão é destinado a estrutura.

O acoplamento entre o contexto e as estratégias é mais apertado do que o O acoplamento entre a abstracção e a aplicação na Ponte padrão.

Pelo que entendi, você está usando o padrão de estratégia quando você está abstraindo comportamento que poderia ser fornecido por uma fonte externa (ex. Configuração poderia especificar para carregar algum plugin montagem), e você está usando o padrão de ponte quando você usa as mesmas construções para fazer o seu código um pouco mais limpa. O código real será muito similar -. Você está apenas aplicando os padrões para ligeiramente diferentes razões

Outras dicas

O padrão Bridge é um padrão estrutural (como você construir um componente de software?). O padrão de Estratégia é um padrão dinâmico (como você quer para executar um comportamento em SOFTWARE?).

A sintaxe é semelhante, mas os objetivos são diferentes:

  • Estratégia : você tem mais maneiras para fazer uma operação; com a estratégia, você pode escolher o algoritmo em tempo de execução e você pode modificar uma única estratégia, sem um monte de efeitos colaterais em tempo de compilação;
  • Ponte : você pode dividir a hierarquia de interface e classe, juntá-lo com uma referência abstrata (veja explicação )

Estratégia:

  • Contexto ligada à Estratégia: (! Possivelmente Abstract mas não é realmente uma interface como o desejo de u para encapsular um comportamento específico e não toda a implementação) O contexto Classe saberia / contêm a referência de interface estratégia e o implementação para invocar o comportamento estratégia sobre ele.
  • Intenção é a capacidade de comportamento de swap em tempo de execução

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

Ponte

  • Abstraction não ligada à Implementação: A interface de abstração (ou classe abstrata com a maior parte do comportamento abstrato) não saberia / contêm a referência de interface implementação
  • Intenção é completamente dissociar a abstração da implementação

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

Ponte : (Um padrão estrutural)

Ponte padrão desacopla abstração e implementação e permite tanto a variar de forma independente.

Use esse padrão quando:

  1. abstrações e implementações não foram decididos em tempo de compilação
  2. abstrações e implementações devem ser alteradas independentemente
  3. As mudanças na implementação de abstração não deve afetar aplicativo chamador
  4. Cliente deve ser isolado a partir de detalhes de implementação.

Estratégia: (padrão comportamental)

padrões Estratégia permitir-lhe alternar entre vários algoritmos de uma família de algoritmos em tempo de execução.

Use Estratégia padrão quando:

  1. Várias versões de algoritmos são obrigados
  2. O comportamento da classe tem que ser mudado dinamicamente em tempo de execução
  3. Evite afirmações condicionais

Related posts:

Quando você usa o padrão Bridge? Como é que é diferente do padrão Adapter?

real Exemplo Mundial do padrão de estratégia

Eu estava pensando o mesmo, mas recentemente tive a ponte uso e percebeu que ponte está usando a estratégia e adicionando abstração para o contexto assim o que você mais tarde pode fazer mais mudanças sem alterar o cliente. Ao usar estratégia sem a abstração do desenho não é tão flexível e pode exigir alterações para o cliente mais tarde. Mas ao usar a ponte inteira o projeto torna-se ainda mais flexível. Aqui você pode se como indo de Estratégia para Ponte dá mais flexibilidade. Também assumimos que agora "visto" e "mestre" não só estão disponíveis em cartões, mas em celulares e chips também; e se usarmos a ponte é muito mais fácil para adicionar esse suporte.

 Estratégia VS Bridge

tipos Design Pattern

  • Comportamental: padrões caracterizar as maneiras em que as classes ou objetos interagem e distribuir a responsabilidade
  • estrutural: padrões de lidar com a composição de classes ou objetos.
  • Criacionais:. padrões estão preocupados com o processo de criação do objeto

Ponte (Estrutural)

Desacoplar uma abstração de sua implementação de modo que cada um pode variar. independentemente. enter descrição da imagem aqui

Tome um controle remoto. O controle remoto tem botões 1-6. Esta é a classe de betão no diagrama acima. Cada botão funcionará diferente, dependendo se o controle remoto é usado para uma TV ou DVD. A funcionalidade de cada botão é captada a partir da implementação pela interface implementador.

Isso nos permite mudar a forma como o controle remoto irá trabalhar para cada dispositivo.

Estratégia (comportamental)

Definir uma família de algoritmos, encapsular cada um e torná-los intercambiáveis. enter descrição da imagem aqui

Na estratégia, se estivéssemos olhando para o cenário remoto. O "estado" é todo o controle remoto que trocar alterando referência estadual do contexto. O "concreteStateA" (TV remoto) "concreteStateB" (DVD Remoto).

Leitura adicional:

Somando-se a resposta de willcodejavaforfood, eles podem ser os mesmos, na implementação. No entanto você usa estratégia para estratégias de swap como classificação estratégia, enquanto você usa ponte para colmatar as implementações de duas objeto dizer um invólucro de banco de dados, e um adaptador de rede para o código do cliente pode usar a trabalhar contra a mesma API. Assim, a nomeação realmente diz tudo

  1. Estratégia Padrão é usado para decisões comportamentais, enquanto Ponte Padrão é usado para decisões estruturais.

  2. Brigde Padrão separats os elementos abstratos a partir dos detalhes de implementação, enquanto Estratégia Padrão está em causa fazer algoritmos mais intercambiáveis.

padrão de estratégia em UML

Padrão Brigde em UML

padrão de estratégia em 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")

Padrão Brigde em 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()

A partir do wiki na Estratégia padrão

O diagrama de classes UML para a Estratégia padrão é o mesmo que o diagrama para o padrão Bridge. No entanto, estes dois padrões de projeto não são os mesmos em sua intenção. Embora a Estratégia padrão é para o comportamento, a Ponte padrão é destinado a estrutura.

O acoplamento entre o contexto e as estratégias é mais apertado do que o O acoplamento entre a abstracção e a aplicação na Ponte padrão.

Apenas a acrescentar ao que já foi dito sobre a comparação padrão (diferença de intenções, ...): o padrão Bridge também está estruturado intencionalmente para permitir o lado da hierarquia abstração para variar. Em linguagens como C # isto poderia implicar que você tem uma base de abstração que contém métodos virtuais como uma forma de permitir variações destinados que não causam problemas para os consumidores existentes. Outros, que os dois padrões pode parecer idêntico para a maior parte.

padrão

Estratégia é usado quando se deseja ligar algoritmo ou estratégia em tempo de execução. Como categoria de padrão também implica que ele lida com o comportamento dos objetos. Por outro lado da ponte é padrão estrutural e lida com a hierarquia estrutural dos objectos. Ele separa a abstracção de aplicação através da introdução de uma abstracção refinado entre eles. abstração refinado pode ser confundida com a estratégia de tempo de execução ligado (padrão na estratégia). Bridge promoções de padrão com os aspectos estruturais, fornecendo um mecanismo para evitar a criação de n número de classes.

Por padrão de estratégia apenas a implementação varia.

Suponha, classe A está usando a classe B, que tem várias implementações disponíveis. Então, nesse caso B seria abstrato com a implementação real fornecido em tempo de execução. Este é padrão de estratégia

Agora, se si A é abstrata. Tanto A como B podem variar. Você usaria padrão Bridge.

Eu acho que há uma ligeira diferença entre eles no contexto que está sendo usado.

Eu uso o padrão Bridge para separar conceitos ortogonais que ambos pertencem a um maior - para deixá-los variar independentemente. Ele geralmente envolve múltiplas abstrações.

IMO, o padrão Strategy é mais simples ou mais plana. Ela serve para OCP com certeza, mas não necessariamente para ser parte de um outro e maior conceito como o padrão Bridge.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top