One of my favorite authors has written on one of my favorite topics. Martin talks about role interface and header interface.
A header interface is an explicit interface that mimics the implicit public interface of a class. Essentially you take all the public methods of a class and declare them in an interface. You can then supply an alternative implementation for the class.
A role interface is defined by looking at a specific interaction between suppliers and consumers. A supplier component will usually implement several role interfaces, one for each of these patterns of interaction.
These are more of styles of designing interfaces. Like Martin, I too prefer the role interfaces. In face I would hesitate to call the header interface an interface, it is just an abstraction. An interface should shoulder the responsibility of explicitly specifying its purpose, which is more than abstraction. It qualifies an object with a capability. And this interface is used anywhere this capability is to be represented.
This is the reason why Interface Segregation Principle gets its significance. It stresses that clients should not be forced to depend upon interfaces that they do not use. Otherwise they might end up having to change themselves because of an unused interface. What this means is that we need to avoid thick interfaces, non-cohesive functionalities should be kept separate. And this is better achieved through the role interface rather than the header interface.
