George Wilson wrote (on 05/02/2014):
The point (at least in Java) is two fold- one is to separate behavior from
implementation to achieve better separation of concerns
[...]
The other (which is really just an application of number one) is using them
to group together different classes under a similar banner (again, in Java
this is really a type issue). You could use this in cases where you do not
want to define an abstract class for instance but still want some
uniformity.
This sounds like a good description of why to use Interfaces in general, but doesn't really explain why it is the language's responsibility to define those interfaces for you, rather than some framework.
Obviously, there is a benefit to using the same Interfaces in multiple projects, and this is what groups like FIG are working on. A similar role in the Java world might be the various Apache Foundation groups working on interoperable tools, but not contributing to the Sun/Oracle JDK directly.
I know a friend of mine up North is a big fan of traits which from what I
can tell are basically an extension of interfaces (please correct me if I
am wrong- I have not used them).
Traits are a slightly different concept, sometimes referred to as "horizontal reuse". They don't create any kind of inheritance relationship between two classes, just allow you to write some code once and use it in several places. Essentially, they are an automated copy-and-paste.
[PS: Please reply below, rather than above, other people's posts, preferably trimming the quote to the relevant part as I've done here.]
Regards,
--
Rowan Collins
[IMSoP]