[From the last episode: There will be many details that don’t matter. In a house example, details of how locks are worked don’t matter when all the door wants to do is order the lock to unlock.]

We have taken the example of a house (using a little imagination to pretend that the house is made of softwareIn this context, "software" refers to functions in an IoT device that are implemented by running instructions through some kind of processor. It's distinct from "hardware," where functions are built into a silicon chip or some other component.). But let’s back up. What are we doing here? We’re defining objectsWhen talking about programs, these are “things” that can be created in a way that encapsulates the details, letting them be accessed from outside through an interface. (or, dare I say, “things”) and we’re saying what we can do with those objects. The details of how that happens is buried inside the code for that object. So if all we’re trying to do is get into the house, we don’t care about the details of how the doors and locks and windows work. We simply want to say, “Unlock the house.”

So we’ve taken all those details and encapsulatedWhen the details of how something works is buried inside the code for an object in a way that lets some other programmer use it without knowing those details, we say that the details have been encapsulated. them inside the objects. We don’t see any of the details from the outside; only the object innards know how to unlock the house. From the outside, we just say, “Unlock the house.”

In the process of unlocking the house, we need to unlock the door. The “door code” describes how you might do that, but, at this level, we don’t care. From the “house code,” we just want to say, “Unlock the door.” Within those details, we might have to unlock two locks. We don’t care about how those locks are unlocked – the “lock code” takes care of that for us. We simply say, “Unlock the main lock” and “Unlock the deadbolt.” The image and video below illustrate this concept.

From Abstraction to Encapsulation to Interfaces to APIs

Here’s the crux: all of the details of an object are encapsulated into the gray boxes. The outside world can’t – and shouldn’t – see those details. All they see are the green commands. Other objects can use those commands – they just can’t see how the commands work in detail.

Those commands? They’re the interface between what’s outside the object and what’s inside. Some interfacesThe point where two different domains meet, like a border. For example, a wall plug could be thought of as the interface between the power grid and the appliances you plug in. can be used only by the people on the team writing a larger program – probably within one company. All of the objects — connected through interfaces — are encapsulated within the final program.

But some programs may make some commands available to the “public,” if you will. This allows other companies or people writing different software to make use of the program. We can call these high-level programs as applications; we call the commands that are visible to the outside world an application programming interfaceCommands or functions that let a programmer control some other program or object or thing, or get data from some object, without knowing the details of how it works., or API.

APIs are important because they let someone use something in a program without having to know the details of how it works. Those details are abstracted away; they’re encapsulated. And it makes a programmer’s life a whole lot easier.

Why should you care? Because we’ll see next time that the API is important for interopThis refers to how well different pieces of equipment can work together. Macs and PCs, for instance have some limited interop, but there are many Mac devices that can't work on a PC, and vice versa. This is an important notion for systems, like the IoT, that involve many different pieces of equipment working together..