In a recent blog post, RoleInterface, Martin Fowler discusses the differences between role and header interfaces:

A role interface is defined by looking at a specific interaction between suppliers and consumers... This contrasts to a header interface, where the supplier will only have a single interface...

The strength of a role interface is that it clearly communicates the actual collaboration between an activity and its successors. Often a class doesn't use all the methods of a class, so it's good to show which ones are actually needed. This can be particularly useful if you need to substitute it later on. A header interface forces you to implement every method, even if you're not going to need them; but with a role interface you only need to implement exactly what's needed.

The disadvantage of a role interface is that it's more effort to come up with, since you need to look at each collaboration to form the role interface. With a header interface all you have to do is duplicate the public methods, no thought needed.

Fowler demonstrates a role interface with an example from project management, with an interface describing an activity or a task:

public interface Activity {
  MfDate earliestStart();
  MfDate earliestFinish();
  MfDate latestFinish();
  MfDate latestStart();
}

class ActivityImpl... {
  List predecessors() ...
  List successors() ...
}

With a role interface... we look at how the collaborating objects are actually used. In this case a successor [task] is only used for its latestStart and a predecessor [task] is only used for its earliestFinish. So as a result we create two interfaces which only have the methods we actually use.

public interface Successor {
  MfDate latestStart();
}
public interface Predecessor {
  MfDate earliestFinish();
}

class Activity {
  List predecessors() ...
  List successors() ...
}

According to Fowler, role interfaces result in a cleaner, more precise definition of an object's responsibilities and interactions. That helps, because, according to Fowler:

My belief has always been that you should only use interfaces when you really need substitutability, and if you do need interfaces you should think hard about what the consumer of that interface needs.

What do you think about the finer-grained role interfaces versus the coarser header interfaces? In what design situations would you use header interfaces?