A while back I wrote an application that interacted with a camera and a signature pad device. Part of the specification was that it be as easy as possible to change the camera hardware in the future to allow for upgrades. The adapter pattern was the perfect solution to this. We used a Canon camera with a COM wrapper .NET SDK which we didn't want the application coupled to.

One interface to adapt them all
I created an ICamera interface that described the way we wanted to interact with a camera. It had basic methods on it like connect, take photo, disconnect etc.

The canon camera adapter
I then created a class that implemented the ICamera interface and contained a Canon camera sdk object. This class was the adapter between my simple interfce and the canon sdk.

Adding another camera
Any camera device that can support the basic functionality prescribed in the ICamera interface can easily be added by creating an adapter class. None of the previous code which makes use of the camera needs to be changed to work with a different device.

The adapter pattern defined
The adapter pattern converts the interface of a class into another interface the clients expect. Adapter let's classes work together that couldn't otherwise because of incompatible interfaces (Freeman et al, 2004). Our application code (the client) and the camera code are decoupled by the adapter and unaware of each other thanks to the ICamera interface.

Testability/Mockabillity
As a side note this approach also meant that all of our client code was testable and that with a flick of the dependency injection configuration switch it could be run without an actual camera device at all (which was useful for testing other parts of the application).