"Hello, Amigo! Today I'd like to tell you the reasons why interfaces exist. You often hear that a certain class, object, or entity supports a particular interface. What does it mean to support an interface?"

Interfaces exist to support specific behavior - 1

In a broader sense, any interface is a mechanism for something to interact with something else. For example, a TV remote is a remote interface. A dog understands and executes commands, which means that the dog supports a voice (control) interface. To sum it all up, we can say that an interface is a standardized way for two things to interact, where both parties know the standard. When a person tells a dog to "sit", his or her command is part of a «dog voice-control interface», and if the dog obeys the command, then we say that the dog supports the interface.

So it is in programming. Methods are actions performed on an object, on its data. And if a class implements certain methods, then it «supports the execution» of certain commands. What do we gain by combining methods into an interface?

1) Each interface, just like a class, has a unique name. Both parties can be 100% sure that the other party supports the exact interface they know and not some similar interface.

2) Each interface imposes certain restrictions on a class that is going to support it. The class (its developer) decides what it will do when the methods inherited from an interface are called, but the result should be within the bounds of reasonable expectations. If we order a dog to "sit" and then it rolls around in place for 5 minutes and then sits, then it supports the interface. But if it instead seizes you by the leg, then we can hardly say it supports the interface. Executing the command didn't produce the expected result.

Let's say you and your friends are writing a computer game. And you've been assigned to program the behavior of one character. One of your colleagues has already written code to display all the characters on the screen. A second colleague, who responsible for saving the game to disk, has written code to save all game objects to a file. Each of them wrote a lot of code and made an interface for interacting with that code. For example, it might look like this:

Java code Description
interface Saveable
 void saveToMap(Map<String, Object> map);
 void loadFromMap(Map<String, Object> map);
— Interface for storing / loading an object from a map.
interface Drawable
 void draw(Screen screen);
— Interface for drawing an object inside the passed Screen object.
class PacMan implements Saveable, Drawable
— Your class, which supports two interfaces.

In other words, to support any interface (group of interfaces), your class must:

1) Inherit them

2) Implement the methods declared in them

3) The methods must do what they were intended to do.

Then the rest of the program's code, which knows nothing about your class and its objects, can work with your class.

"Why can't the code know anything about my class?"

"Let's say you took the code from a program that someone wrote a year ago. Or suppose your friends bought/licensed the game engine from someone else. You have working code for the game. Thousands of objects that interact with each other. And they can easily interact correctly with your objects if you make that interaction happen through interfaces that your classes have correctly implemented."

"Far out! I didn't know that was possible."

"All big projects work like this. People stopped writing from scratch a long time ago."

People also don't reinvent math and the alphabet every time. Instead, they study everything that was invented before them.