Interfaces aren't so much about saving time as they are about having a consistent interface for some group of classes. It's like a contract, everything that implements IBody must implement the Eat method, no matter what's actually underneath it.
So without an interface, you wouldn't know if Cat, Bird, Monkey implemented eat or if it did if it did it properly.
But with an interface, you could have a big collection of objects that you want to call the Eat method on.
Remember you can create an IBody reference to these objects:
Code:
IBody animal1 = new Cat();
IBody animal2 = new Dog();
animal1.Eat();
animal2.Eat();
The power in this isn't always readily apparent, but take a look at all the collections classes and how they are set up with interfaces to get an idea. Likely there'll be a Collection interface which has methods like get, put, sort, etc.. so in my program I can just use a Collection interface to do what I'm doing.. then say 6 months down the road I need to use a different kind of collection because of memory concerns or thread safety or whatever, I can change which implementation I use without having to recode and test a ton of code. I just say Collection stuff = new HashMap() instead of Collection stuff = new Vector() and the stuff underneath is changed.
So yeah, think about it as a contract, anything that implements an interface is guaranteed to have specific methods.