Introduction: Interfaces

Consider the power outlets in North America. They all look more or less the same. Any company who intends to build a system that needs power uses a cord that plugs to these outlets. The interface between the devices and powerlines are clearly defined. The electricians who make the power outlets always build them the same way. The device makers who produce the plugs build them such that they work with the outlets. The device makers do not need to know how the power reaches the outlet. They know as long as their plug matches the specification for the "outlet interface" it will receive power. 

Another real-world example that can teach us about interfaces is a restaurant menu. The menu is the interface between the customer and the kitchen. There is a list of food options which the customer can choose. The details of how the food is prepared are hidden away from the customer. As long as the customer can read the menu and pick an option, the rest is taken care of. 

Let's take a TV remote as another example of an interface. There are lots of TV remotes out there, each with their own sets of buttons and features. But there are usually some core features of TV remotes. To name a few: a power button, buttons to change the channel, and buttons to adjust the volume. These buttons serve as a sort of API for the remote. You may not know how each of these buttons magically does the things they do, but you know that pressing the power button turns the TV on/off or pressing '+' on the volume button will increase the volume and so forth. That's okay -- you don't need to know how the remote transmits signals to the TV to give it these various commands. The only thing you need to know is what each button does. Because of the API built into the remote, the average person can use rather sophisticated technology.

For the last example, let us look at a typical email inbox. Once again, you have various buttons to click that each does different things. Suppose you've opened up an email. You can choose to reply, forward, delete, mark as important, print, etc. These seem like simple commands. "What does the delete button do?" "Oh, it deletes the email." And that's about as far as the explanation can go. Does "deleting" the email mean that the data is erased by replacing every bit with 0? Does it mean that the email is moved to another memory space? Does it mean that the email can't be accessed by your account but is floating around somewhere on the server? You don't know. The interface is used to mask information like this, making the usage smoother and more straightforward. The only way users can use your application is by using the options that you give them, and they won't know how the application processes each command that it is given.

In programming, we strive to build interfaces similar to the above examples. Some code is providing a service; some code is using that service. As long as a clear interface defines their interaction, they do not need to know about the details of what each side of the communication is doing on its own. In programming, this interface is called Application Programming Interface or API.