Dependency Inversion Principle
2. In case this is a correct approach, when and where should I apply this? Should I really create an "interface" for each and every dependency I might have, if not, how do I destinquish between cases where it makes sense and where not?
'interface' means the portion of a class that is publicly visible. The interface does not have to be a separate pure virtual class (interface in Java / c#).
The key idea behind the Dependency Inversion Principle is that the clients impose the interface on the servers, not the other way around. The interface is owned by the clients and is designed to meet their needs.
In an attempt to adhere to this principle I started introducing pure virtual classes everywhere, but I realised that they were adding unnecessary complexity. As long as the server's interface is imposed by the client it doesn't matter if the interface is defined separately by a pure virtual class or not.
I generally treat pure virtual classes exactly as I would treat any super class. The top level class of an inheritance hierarchy should contain as much common functionality as possible (Don't Repeat Yourself). The application of the DRY principle usually dictates the type of class that will sit at the top of my inheritance hierarchies.
In saying that, sometimes a pure virtual class makes sense, as a pure virtual class describes what an object does, and not what an object is.
These principles are tools to help you manage the complexity of your design. They are a guide only and applying them effectively comes with experience.