"Separate interfaces so callers are only dependent on what they actually use"

Or, more simply…

Avoid "fat" interfaces

This principle is about breaking down our interfaces to be highly cohesive. You might have a server that provides methods to a number of different clients as such:

Class diagram. 3 client classes depend on single concrete server implementation

If one client requires changes to the server methods it calls, you have to change the server. Since all clients depend on the server, the change impacts all of them and you risk a change that should be isolated to a single client having adverse impacts on all of the clients. In other words, the above design results in unwanted coupling between the clients.

This can be solved by creating client-specific interfaces that are limited to only those functions required by the client (see: adapter pattern). In this way, even when you have classes that are perhaps more complex or less cohesive then you’d like, you can at least isolate this complexity:

Class diagram. Each client depends on its own Server Interface, each of which are implemented by the single concrete server implementation