/**
 * @returns true if all items of this order are in stock,
 *          or false if we must order an item ourselves.
 */
public boolean allItemsAvailable(Order order) {
  Collection items = order.getItems();
  for (Iterator i = items.iterator(); i.hasNext(); ) {
    OrderItem item = (OrderItem) i.next();
    if (! itemAvailable(item)) {
      return false;
    }
  }
  return true;
}

class MyClass {
  public myFunction() { }
  private MyOtherClass myField;
}
[/pre]
[i]Often people think of the interface of the class as being only "myFunction" but in fact it includes the dependency on "MyOtherClass". What can be a problem is that a call to "myField" could concievably result in a corruption of this.[/i] 
 
This discussion becomes completes nonsense if you start mixing up interface and implementation. The dependency on MyOtherClass is definitely part of the implementation and *not* of the interface. That's what we have all learnt in our first OO lesson. If the point of this back interface "revelation" is the realization that interfaces don't exist in isolation, they also need an implementation which usually depends on other interfaces/components or whatever, wow, who would have thought that. Do you want to convince us to give up or relativize the interface / implementation separation? You are trying to blow up the whole OO enterprise, that's what you are doing! 
 
When I design a database interface, of course there will be wires going out of my "box" connecting it to the database box. But the whole point of wanting a DB interface is to make sure that a client can, and should, use it without caring about those wires, and without caring about which particular DB box it is connected to. Where's the problem with that?

class MyClass {
  public myFunction() { }
  private MyOtherClass myField;
}