Because you can then indicate things like this method takes an argument, which can be of any class that implements this interface. It’s not for the benefit of the classes that implement it, but the code that uses those classes. For instance, one way to build an object-relational mapper in PHP might be to create an interface that all storable objects had to implement. You could then build your class hierarchy ignoring the fact that they’re all storable in your database, and put all the code relating to database access in the methods declared by the interface. This way, if there is some object that shouldn’t be stored in the database, or that requires special handling before going into the database, the code will still conform to the interface even if it doesn’t have the same implementation. You can see this pattern in Apple’s Cocoa framework: there’s an interface called NSCoding that declares the methods necessary to serialize an object. User-created objects that conform to the NSCoding interface and implement the necessary methods can be saved to and loaded from files without any extra work on the part of the programmer. The other principal way to do this is multiple inheritance, which causes a lot of problems. And the reason this is a good thing is because having isolated bits of code that communicate with each other through well-defined interfaces (in the generic sense) leads to more maintainable code. Instead of knowing how the other chunk of code actually works, you just know that if you call this function with these arguments, this other thing will happen. Interfaces (in this specific sense) are a way of formalizing the contract between the caller and the called code.