Interfaces in the Real World
Before we dive into OOP, let's think about interfaces in the real world.
This is an interface:
This is also an interface:
And, so is this:
These are all interfaces that allow me, an external consumer, to interact with the system behind it.
- The light switch is the interface that allows me to turn a light on or off.
- The gear shift in my car is the interface that allows me to interact with the transmission. (Yes, I’m a manual transmission guy!)
- The keyhole is my interface to the locking system of my door. It's what I interact with in order to lock or unlock my door.
It's important to notice that, in all three of these cases, I didn't have to open anything up in order to accomplish my goal. For example, I didn't have to unscrew the door knob off of the door and poke around inside in order to activate the lock. Instead, I just use the interface – the keyhole.
Back to Programming
In each example above, the object has two sides to it.
- The part that I interact with – e.g., the light switch
- The part that does what I'm trying to accomplish – e.g., the mechanics of completing or breaking the electrical circuit.
Likewise, classes that you write have two sides to them.
- The part that calling code can interact with – the interface
- The part that does what that calling code is trying to accomplish – the implementation
Broadly speaking, an interface consists of any methods and variables that can be accessed outside of the class itself. Using a rather naïve understanding of electrical engineering, let's take a look at some C# code that models the light switch, and see what's part of the interface and what's part of the implementation:
Although the class file itself includes both the private and public methods and variables, it's critically important to mentally make the distinction between the external interface and the internal implementation.
Personally, I've got only a rough idea about locking mechanisms in a door knob. But I know how to put a key in and lock or unlock the door. Likewise, any code that uses your class shouldn't have to know the details of how your class does what it does. It just needs to know what methods to call to get the job done.
Interface Types
Languages like Java and C# formalize the notion of an interface by giving it a type of its own. (To distinguish between the broad definition above, and the type, which we're discussing here, I'll use lower-cased interface for the definition above, and upper-cased Interface for the formal type.)
An Interface looks similar to a class, but contains only the public parts. Here's an example of an Interface for our LightSwitch class above:
As you can see, this declares the interface of the switch, without any information about how it does what it does. It includes the two methods that the calling code needs to know in order to use it, but the methods have no body to them. That's because we're leaving the body's definition to the implementing class!
Now, our LightSwitch class just needs to declare that it implements that Interface, like so:
Now, it's polymorphin time! When you instantiate the class, you can assign it to a variable declared as an ISwitch (an Interface type) rather than LightSwitch (a class type):
So an interface is...
- the publicly exposed part of a class, which might or might not be formally declared
- a feature of some object-oriented languages that declares certain exposed parts of a class
In an upcoming post, I'll take a look at why you might choose to use an Interface type, and why you might not.
(Photos in this post are brought to you courtesy of my wonderful wife!)
No comments:
Post a Comment