Yup you got it… technically they are wrappers as well, however they aren’t labelled this way.
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.
Let’s use a hard drive as an example, you have directories which you can think of as branches, and you have files, you can think of these as leaf nodes. Branches contain leaves just like directories contain files. Directories and files are both separate entities, but the goal of the composite pattern has them interchangeable, as always this means they should implement the same interface. Example methods that they both share include updating the owner and group, changing permissions, fetching size, created date or last modified date, etc.
Flyweights can be useful when you have a collection of objects, that contain repetitive attributes and you want to share these attributes, the end goal being to save on memory usage.