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)

Design pattern types

• Behavioural: patterns characterise the ways in which classes or objects interact and distribute responsibility
• Structural: patterns deal with the composition of classes or objects.
• Creational : patterns are concerned about the process of object creation.

Bridge (Structural)

Decouple an abstraction from its implementation so that each may vary. independently.

Take a remote. The remote has buttons 1-6. This is the concrete class in the diagram above. Each button will work different depending on if the remote is used for a TV or DVD. The functionality for each button is abstracted from the implementation by the implementer interface.

This allows us to change how the remote will work for each device.

Strategy (Behavioural)

Define a family of algorithms , encapsulate each one and make them interchangeable.

In strategy, if we were looking at the remote scenario. The "state" is the entire remote which we swap out by changing the context's state reference. The "concreteStateA" (TV remote) "concreteStateB" (DVD Remote).

Additional reading:

• Java design principles and patterns
• Design Patterns

Adding to willcodejavaforfood's answer, they can be the same, in implementation. However you use strategy to swap strategies such as sorting strategy, while you use bridge to bridge the implementations of two object's say a database wrapper, and a network adaptor so the client code can use either working against the same API. So the naming actually says it all

From the wiki on Strategy pattern

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.

In the Strategy pattern, the activities of the "Parent" for a particular operation are constant whereas the activities of the "Child" can vary. However, in the Bridge Pattern, the activities of the Parent, as well as the Child, can vary.

So, for example,

public class Ticket {
    
    Date dateOfTravel;
    int distance;
    Vehicle vehicle;
    Seat  seat;
    
    public float getTotalFare(){
         //depends on 
               //Distance
               //Vehicle - whether Vehicle is AC or non-AC. 
               //Seat - based on the location of the Seat.
     
        //Fare = vehicleBaseFare*seatMultiplier*distance

    }
    
}

In the above, the variations depend on the Parent (distance) as well as the children (Vehicle and Seat). So, here Vehicle and Seat both acted like Bridge.

Now, here

public class Vehicle {

   TrackingDevice device;

   public Coordinates getCoordinates(){
       return device.getCoordinates();
   }
}

Here, the Parent's role was constant, i.e., nothing! So, this was a Strategy pattern.

In addition to use case differences explained by other answerers there is other thing to think of.

Seem like Bridge is a combination of Strategy and Template method behavioral patterns. So, we call methods in the same order as in Template method and change its behavior depending on given implementer as in Strategy pattern.

Doesn't it mean that two behavioral patterns along create a structural pattern? Either could we use Bridge pattern in behavioral way?