Geoff Hulten, in collaboration with 
Johan Ovlinger and Doug Orleans and Karl Lieberherr, 
has outlined the need for interface class graphs in 
the very rough draft paper: 
http://www.ccs.neu.edu/research/demeter/biblio/components/demPaper.PDF
Here is a summary why we need interface class graphs:

1. Writing strategies directly for a class graph breaks encapsulation. The strategy might have to talk about unimportant implementation details which is against the idea of AP.

2. When a class graph changes it is time consuming to check and update the individual strategies.

Consider a class graph cg and an APPC with strategies s1, ... ,sn.
We require as a minimum that cg is compatible with s1, ... ,sn. The problem with this approach is that updating of cg to cg' may require the updating of n strategies to make them select the right paths in cg'. This might reveal a lot of representation information.

Consider a class graph cg and an APPC with interface class graph icg.
icg may be viewed as the "merging" of the n strategies.
We require as a minimum that cg is compatible with icg and icg is compatible with s1, ... ,sn. The benefit of this solution is that for a new class graph cg' it is only necessary to express how each edge of the icg is implemented in cg'. This might also reveal implementation information but it is now outside the APPC as part of the instantiation of the APPC. The APPC itself is not polluted with representation information.
 
It is important to notice that with and without an interface class graph an APPC works for an infinite family of class graphs. The key contribution of icgs is that they facilitate reuse of APPCs by localizing changes to the class graph to a new mapping of icg to cg.

Example: Assume that cg' requires that the strategy edge P->Q be replaced by the strategy edges P->X->Q. This might require updating all strategies with information about class X. With an icg, the update will be easier. The icg contains the edge P->Q and the strategies don't have to refer to X. We will specify once, as part of the instantiation of the APPC that P->Q is mapped to P->X->Q.
The reason for the need that X is mentioned is that some other APPC needs a path from P to Q not going through X. 

An alternative to using interface class graphs to shield strategies from class graphs would be to use a strategy updating approach. Statements like: replace P->Q by P->X->Q in all strategies or in a subset of the strategies. But the interface class graph solution seems better since
it helps to explain an APPC when it is presented with an interface class graph.