It sounds like you're talking about "contracts" here not "interfaces" (as I understand the term).

The interface term usually refers to the method signatures of a class, and these days is pretty much synonymous with the Java system of not having multiple inheritance of behaviour - just interface. Which, as a way of avoiding the problems with multiple inheritance, is throwing the baby away with the bathwater as far as I'm concerned.

Just looking at method signatures isn't enough to figure out whether XYZ "does the same action". This is where contracts can be useful. You explicitly state in your pre-conditions and post-conditions what the requirements and result of the method should be.

Many of the problems that occur with multiple inheritance in languages like Java and Perl disappear in languages like Sather and Eiffel where you have contracts (to keep you using inheritance only when appropriate) and support for multiple inheritance (allowing good resolution of naming issues, diamond inheritance, etc.) built into the core language.