Given a particular third-party class/library you want to make use of, the simplest thing to do would be to just hardcode API calls to it through your application.On the other hand you have the possibility of defining a interface that generically dictates what you want -not how-, and then follow the Adapter pattern to bind your interface to the third-party class.I currently feel inclined to the second option because:It creates a single point of change if you ever want to replace the functionality providerIn a similar way, it allows you to add more providers without changing your application codeIt permits following your own naming conventions, simpler method signatures, etcThe thing is, I'm not experienced with this approach and I don't know how complicated or inconvenient it can get. I'd also like to know if are there any common errors when following this pattern.In my particular case I don't want to wrap either a giantic library -e.g. a GUI- or a small function. Also there are actual possiblities I'll change my provider in the future, so this is not a YAGNI.Thank you
Should one define an interface and code an adapter for it whenever a dependency is found?
design patterns;adapter
The dependency inversion principle suggests you should:High-level modules should not depend on low-level modules. Both should  depend on abstractions.You should write your code against a clear and simple abstraction of whatever external services you may need (i.e. a complex GUI toolkit in your case) and then just write implementations, whether that is by hand or as an adapter for 3rd party components.