The bridge pattern is another structural design pattern. The design pattern states that the bridge pattern should decouple an abstraction from its implementation. That sounds a lot one of the main goals of OOP, programming to an interface using polymorphism and abstraction to achieve inversion of control.
As much as that’s what it sounds like, that’s not the goal of the bridge pattern, it’s more the means of achieving the goal. I like to think of the bridge pattern as a multi-dimensional strategy pattern. I’ve not covered the strategy pattern yet but you can think of it as providing an interface to build multiple strategies or algorithms which can be selected at run time.
The bridge pattern differs from this, in that you build two collections of strategies, where all strategies from one interface can make use of the strategies from the other interface. As an example lets assume you have a device strategy with 3 implementations (Phone, Tablet & Laptop), you also have 3 messaging strategies (Skype, WhatsApp, Facebook). The goal is to build an application where every device can interchangeably use every messaging platform using composition.