What is the difference between the bridge pattern and the strategy pattern?

Semantics. From wikipedia:

The UML class diagram for the Strategy pattern is the same as the diagram for the Bridge pattern. However, these two design patterns aren't the same in their intent. While the Strategy pattern is meant for behavior, the Bridge pattern is meant for structure.

The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

As I understand it, you're using the strategy pattern when you're abstracting behavior that could be provided from an external source (eg. config could specify to load some plugin assembly), and you're using the bridge pattern when you use the same constructs to make your code a bit neater. The actual code will look very similar - you're just applying the patterns for slightly different reasons.

The Bridge pattern is a structural pattern (HOW DO YOU BUILD A SOFTWARE COMPONENT?). The Strategy pattern is a dynamic pattern (HOW DO YOU WANT TO RUN A BEHAVIOUR IN SOFTWARE?).

The syntax is similar but the goals are different:

• Strategy: you have more ways for doing an operation; with strategy, you can choose the algorithm at run-time and you can modify a single Strategy without a lot of side-effects at compile-time;
• Bridge: you can split the hierarchy of interface and class, join it with an abstract reference (see explication)

I was thinking the same, but recently I had to use bridge and realized that bridge is using strategy and adding abstraction to the context so that you later can make more changes without changing the client. When using Strategy without the abstraction the design is not as flexible and may require changes to the client later. But when using the whole bridge the design becomes even more flexible. Here you can se how going from Strategy to Bridge gives more flexibility. Also we assume that now "visa" and "master" are not only available on cards but on phones and chips also; and if we use bridge it is much easier to add that support.

Strategy:

• Context tied to the Strategy: The context Class (possibly Abstract but not really an interface! as u wish to encapsulate out a specific behavior and not the entire implementation) would know/contain the strategy interface reference and the implementation to invoke the strategy behavior on it.

• Intent is ability to swap behavior at runtime

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

Bridge

• Abstraction not tied to the Implementation: The abstraction interface (or abstract class with most of the behavior abstract) would not know/contain the implementation interface reference

• Intent is to completely decouple the Abstraction from the Implementation

  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: ( A structural pattern)

Bridge pattern decouples abstraction and implementation and allows both to vary independently.

Use this pattern when :

1. Abstractions and implementations have not been decided at compile time
2. Abstractions and implementations should be changed independently
3. Changes in implementation of abstraction should not affect caller application
4. Client should be insulated from implementation details.

Strategy: ( Behavioural pattern)

Strategy patterns enable you to switch between multiple algorithms from a family of algorithms at run time.

Use Strategy pattern when :

1. Multiple versions of algorithms are required
2. The behaviour of class has to be changed dynamically at run time
3. Avoid conditional statements

Related posts:

When do you use the Bridge Pattern? How is it different from Adapter pattern?

Real World Example of the Strategy Pattern