One of the things I often struggle with when writing code is naming things. Naming things well is especially important for interfaces, they're likely used in more places than the concrete types in a loosely coupled OO system.

One guideline I've found that helps me is something I like to call the "ICanHasCheezburger naming style". I typically start all my interface names with I (most of my code is C# at the moment), so that part is easy - after that, you just describe the specific reason that the interface exists.

So, if you're writing something for getting the GPS location on a phone - instead of calling the interface something like ILocationManager, call it IProvideLocation or ILookupLocation. It makes it very clear to anyone reading the code what the responsibility of that interface.

Sometimes I might write a single concrete class implementing more than one of these interfaces, because they pretty much always end up as Role Interfaces and that's fine. I like to keep my interfaces narrow if I can. However, the main thing this avoids is accidentally bloating the interface as time goes on. It's much harder to allow yourself to expand the scope of something called IProvideLocation than it is to expanded the scope of ILocationManager - which means you end up following the Interface segregation principle with very little effort.