What is an interface?
Interfaces are my favourite part of programming. They’re the part that makes me stop for a second (or a minute, or an hour, or a day) and actually think about my job. Because my job isn’t really about writing code.
Before we get into what is about though, I want to define “interface”.
What is an interface, anyway?
As you probably know, I’m a big fan of the mentality driving specification by example. So let’s think about examples.
Java or C#’s
interface is probably the one you had in mind when you
read the title of this post. We use it to define the exposed methods on
an implementing class. That’s what it does. But what’s it for?
We usually use interfaces (Nat Pryce and Steve Freeman aside) when we’re creating code that a consumer sees, whether it’s ourselves in another area of our code, another developer on our team or perhaps even a third party. They’re often used to provide documentation to the user, either using documentation tools such as Javadoc or simply good naming, and expose the parts of the code base which do the useful thing our module or layer provides.
Often, interfaces are also used to help decouple code. This works
particularly well when rather than trying to refactor classes to the
point where an interface can be extracted, we start with the interface
and define the concrete implementation later when we need it (like Nat
and Steve told you). This doesn’t have to be an
necessarily, but it does require we attempt to use its members before we
implement them, either through TDD or the “write your code, then
implement it” approach loved by Rubists.
This is getting somewhere, but before we start forming any conclusions, let’s look at a related type of interface.
The Application Programming Interface
APIs are great. I wish all applications had one or more. Whether it’s RESTful, uses RPC, works over HTTP, sockets or is purely in memory, all programs should be able to talk to each other somehow. Though it’s not often explained in these terms, this is also the Unix programming model: small programs that can invoke each other and have a common data interchange format—plain text.
We’ve all dealt with APIs, both good and bad. The bad ones are the ones I remember: the APIs that expose half of the functionality and make you either reimplement the other half or jump through various hacks to achieve your goal (I’ve been spending a lot of time writing Java reflection code recently). The good ones, on the other hand, are simple, discoverable, expose all functionality without leaky abstractions and give us access to data in a generally tidy fashion.
A world of difference, and it’s often in the way they were developed. Good APIs are thought about before the product even exists, whereas bad APIs are often an afterthought, attached to the product to simplify a particular task whilst neglecting anything that deviates from the requirements.
We mentioned Unix tools, so this is probably a good time to talk about their particular brand of interface:
The Command Line Interface
This one scares a lot of people, including many developers. The CLI is
an intimidating place when you start, but as any
vim lover will tell
you, once you dive in, you’ll have a hard time retreating to the
comforts of your shiny Apple GUI. So what is it that the command line is
Often, I find myself using the terminal on my Unix of choice when I have
something vaguely complex to do with text. At this point, I often don’t
need to see the intermediate steps, just the overall output, and each
step is probably intricate enough that making a graphical user interface
with enough settings would probably result in something resembling a
computer built in 1944.
Functionality, speed and the ability to iterate are paramount; if I need
beauty, I’ll add it myself. So the best tools are those that spit out
something standard; instead of producing output that looks good for the
particular words on screen, show me something that looks the same no
matter what the output. Pretty-printing a table using hyphens and pipes
is great when I’m doing simple things, but as soon as I want to build it
into something more interesting, I need the capability to switch the
tool to showing tab-separated values instead. If you won’t give me that
But sometimes we do care about shiny things. For that, we have:
The Graphical User Interface
The reason I own a Mac, ladies and gentlemen. It has a terminal when I need it, but mostly it’s just a very, very pretty rectangle that shows me the Internet. And the trackpad is pretty amazing, too.
When I imagine a good GUI, a few applications come to mind. Google Chrome is one, and the built-in Calendar app is another; Eclipse, decidedly not. Why do I care? Because a good UI enables me to do more things, and to get them done faster.
A good graphical user interface gives me the minimum number of tools to get exactly what I want done. For a web browser, this means almost no “chrome” at all (which is why Chrome is an ironic name). The fewer buttons, the better. Hiding the menus, only showing bookmarks on the New Tab page and not showing the Forward button unless it’s necessary are all great examples. Context-sensitivity is very important, which means the designer has to understand the user, and think about their flow through the application.
Sensible defaults are also incredibly important. If I can’t see how to do the task I have in mind just by looking at the controls available to me, I’m not going to be able to guess. If I have to look at the Help pages, you’ve lost my interest. I’ll probably find something else that does what I want.
The behaviour of the application should reflect the needs of the user; a good GUI is one that is instantly obvious. This doesn’t happen by accident.
So what does all this mean?
Interfaces crop up everywhere in software development, from the very low level to the very high. The reason they interest and challenge me is because they’re not easy; you’re always thinking about the user when creating them, and the user probably isn’t you. Building an interface requires you to step out of your personal universe and into someone else’s, and attempt to understand how it is they want the computer to operate. It requires creating for the benefit of someone else.
In short, interfaces are about design.
If you enjoyed this post, you can subscribe to this blog using RSS. I personally use Feedly; you can subscribe here.
Maybe you have something to say. You can comment below, email me, or toot at me. I love feedback. I also love gigantic compliments, so please send those too.