I tried to read many articles on dofactory, wikipedia and many sites. I have no idea on differences between bridge pattern and the strategy pattern.
I know both of t
Just to add to what has already been said about the pattern comparison (difference of intent, ...): the Bridge pattern is also intentionally structured to allow the abstraction hierarchy side to vary. In languages like C# this could imply you have an abstraction base that contains virtual methods as a way to allow intended variations that don't cause problems for existing consumers. Other than that the two patterns might appear identical for the most part.
I think there's a slight difference between them in the context they're being used.
I use the Bridge pattern to separate orthogonal concepts which they both belong to a bigger one - to let them vary independently. It usually involves multiple abstractions.
IMO, the Strategy pattern is simpler or more flat. It serves to OCP for sure but doesn't necessarily to be part of another and bigger concept like the Bridge pattern.
Design pattern types
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:
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.
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.