I know, this question was asked many times, but I did some research and still don't get it, probably you can help me out:
As stated many times, the UML is almost the same. Also the implementation and idea is more or less the same: Instead of sub-typing, you define an Interface, which encapsulates some logic and let's it pass to an abstract.
So, even the Microsoft-Blog guys
The simple answer is “They are similar but different”. The
implementations are similar but the intentions are different. To give
an analogy, a city bus and school bus are both similar vehicles, but
they are used for different purposes. One is used to transport people
between various parts of the city as a commuter service. The other is
used for transporting kids to schools.
They both look the same on the surface to me as well. The main
difference I see is the fact that in the Bridge pattern, the
abstraction is PART OF the object, but in the Strategy pattern the
abstraction is performed BY the object.
Define a family of algorithms, encapsulate each one, and make them
interchangeable. Strategy lets the algorithm vary independently from
clients that use it.
You say "Strategy" when you want to vary behavior, and you do so not
by writing different objects but by introducing a class heirarchy. You
say "Bridge" when you expect that you will vary both the interface and
the implementation. In both cases you're providing flexibility for a
changing implementation; in a Bridge, you're also expecting the
interface to change.
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.
and you're using the bridge pattern when you use the same constructs
to make your code a bit neater.
Wikipedia UML Diagram for Bridge Pattern:
Abstraction and Implementation can change independently.
Regarding your other queries:
Is this probably the main-difference? Since the Implementor and the Abstraction are so loose coupled, I can change the Interface of the Implementor and the Abstraction doesn't have to care? That sounds reasonable, but wouldn't then have the Abstraction to change as well, since they are kindahow connected?
I will explain the difference based on my documentation link about bridge-pattern-implementation-in-java. Even though the example is in java, it can be easily understood for c# developers.
In linked example:
Vehicle : Abstraction Car : Re-defined Abstraction Truck : Re-defined Abstraction Implementor : GearShifter ConcreteImplementor: ManualGearShifter ConcreteImplementor: AutoGearShifter
GearShifter can change independently.
Vehicle changes, only
Truck have to be changed.
GearShifter changes, only
AutoGearShifter need to change.
GearShifter(implementation) through composition, changes in
GearShifter does not affect
GearShifter ( implementor) does not contain or refer
Vehicle ( abstraction), changes in abstraction does not effect implementation.
Bridge pattern presents two orthogonal class hierarchies - One is for Abstraction and one is for Implementor, which can be changed independently without dependency on other.