When to use interfaces instead of classes

A few years ago, I started seeing developers use interfaces instead of classes in a lot of places. This is a good thing, because it has taken a long time for many developers to really understand object-oriented programming (OOP), and a lot of programmers (myself included) were disguising imperative code with just enough OOP to make things compile. Unfortunately, in many of these scenarios, the technique was being abused or overly used.

Here's a look at some of the situations where it makes sense to use interfaces instead of classes, and where is does not. But first, I'll explain what an interface is at the simplest level.

What exactly is an interface?
An interface defines common functionality across unrelated classes. For example, all sorts of classes that look nothing like each other may have the need to safely get rid of the resources they use.

The IDisposable interface (the name for it in .NET) defines a Dispose() method, which classes then implement. A programmer using those classes knows that, if a class implements the IDisposable interface, the Dispose() method is used to safely release resources.

An interface is a guarantee that certain functionality will work in a standardized way. When properly fashioned, an interface encompasses only the bare minimum for the defined functionality. IEnumerable (which is used to iterate over sequences, lists, sets, etc.), for example, does not provide for a Count property, because it is not concerned with "how many?" it is only worried about "the next one in the sequence".

APIs
I believe you get the most advantage from using interfaces as often as possible when you are writing an API. In an API, you want your code to be as loosely coupled as possible in terms of input and output; after all, you have no control over what the consuming application will need.

There may be a time when it is tempting to work with a List; within a piece of code, and then just return the List, for example. The consumers of the API usually do not need all of the functionality of List, and you can output IEnumerable; instead. This way, if the consumer wants a List, they can have it, or they can have an array of T, or whatever else they might need. By using the common denominator interfaces in your API, you free the consumers from being forced to use or convert to/from your class of choice.

Tightly coupled code
In the fantasy land of Computer Science courses and the blogosphere, developers never write tightly coupled code. In reality, tightly coupled code is a fact of life for the average developer.

You aren't going to make an abstract class and implement the Factory pattern to "future proof" yourself against changes when writing a three line of code class will give you a strong type to shuffle data around. Likewise, coding to interfaces is impractical in many situations; a key sign of this is when you find yourself writing classes that look a lot like structures.

If the only or the best way to get something done is to tightly couple code, then trying to abstract some kind of common functionality into an interface is either doomed to fail or merely more effort than it is worth.

Future proofing
Working with interfaces can give you a measure of future proofing when you are on the consuming end of things. If you are using a library that outputs interface instances instead of classes, not recasting those instances as classes can protect you from changes down the road. Along the same lines, if you only need a certain subset of functionality contained within an interface, working against that interface is better than working against the class.

Go back six or seven years before we had generic types--if you had coded everything to take arrays or Hashtables instead of IEnumerable or ICollection, then if the library ever changed to use List or Dictionary you would have a long road ahead of you to convert over.

Code clarity
Coding with interfaces can improve code readability. How? Because there are fewer "moving parts" for the reader to keep in mind. When you work with an interface, it is more clear what your intentions are and what the capabilities will be. Code is more self-documenting when working with interfaces for this reason.

Sometimes an interface just won't do
Some folks take the use of interfaces to an unworkable extreme. Avoid this at all costs. There will be times when you simply cannot boil down the essence of a variable or a method parameter (or whatever) to an interface. In fact, this is more likely than not. Don't try to force the issue; it's better to just use a class and move on with your life than to try to make things work with an interface.

Adobe AIR brings the Web to the desktop

One of the points of my article about the qooxdoo JavaScript library was the concept of building Web applications with a rich user interface that mimics desktop applications. This is good if you want to mimic the look and feel of a desktop application within a Web page. On the flip side is bringing the Web to the desktop - that is, leveraging Web development skills on the desktop. The Adobe Labs has released the Adobe Integrated Runtime (AIR), which provides this functionality.

Adobe describes AIR as a cross-operating system runtime that allows developers to leverage existing Web development skills to build and deploy rich Web applications to the desktop. It provides support for Flash, Flex, HTML, JavaScript, and AJAX.

Getting it

To get started with AIR development, you must install the AIR runtime on your computer. Once it is installed, you may download sample applications to see AIR in action and possibly take a peek under the covers at its code.

There are two downloads relevant to AIR development:

• Runtime provides the runtime environment for running AIR applications. Downloads are available for both Windows and Macintosh operating systems.
• Software Development Kit (SDK) provides everything necessary to build AIR applications. This includes templates, Adobe AIR APIs, and debugger and developer tools. The SDK is available for both Windows and Macintosh platforms. The command line debugger and developer tools require a Java installation (JRE or JDK version 1.4.2 or newer).

Additional downloads are available that allow you to build AIR applications within specific Web development tools:

• Adobe Flex Builder 3: Includes support for building Flex applications on Adobe AIR from within Flex Builder.
• Adobe Flex SDK: Allows you to build AIR applications via Flex.
• Adobe AIR Extension for Dreamweaver CS3: Adds support for building AIR applications within Dreamweaver CS3.
• Adobe AIR Extension for Flash CS3 Professional: Allows you to build AIR applications with Flash CS3 Professional.

In addition, a plug-in is available for the Aptana IDE. Once the runtime is installed, you can easily install and run AIR applications, and the SDK allows you to build AIR applications.

AIR HTML application basics

This article focuses on using standard Web technologies HTML and JavaScript to build an AIR application. AIR uses WebKit to parse, layout, and render HTML and JavaScript content. The AIR API provides host classes and objects for providing desktop applications functionality like reading and writing files and managing windows. In addition, an HTML-based AIR application has the Flash API available to it.

An important distinction of HTML-based AIR applications is that the use of the AIR API is optional. That is, you may choose to use only standard HTML and JavaScript to build an application and run it via the AIR runtime. The runtime includes an HTML renderer and JavaScript interpreter in addition to other features.

There are at least two files in every HTML-based AIR application. The first is an application descriptor file that specifies the application metadata via XML. The second file is a top-level HTML page. Also, AIR provides a JavaScript file (AIRAliases.js) that provides aliases for AIR API classes. More robust applications will include more files like Web pages and JavaScript code.

The AIR SDK includes plenty of sample code for getting a feel for the platform. The following sample code is included in the documentation to get you going with a first, simple application (the ever present Hello World demo).

The following descriptor file provides the details of the application. It references the AIR namespace and assigns a name to the application (Hello World!). The initalWindow element defines application startup behavior as an HTML file (Hello.html) is loaded.

<?xml version="1.0" encoding="UTF-8"?><br /><application xmlns="http://ns.adobe.com/air/application/1.0.M5"<br />appId="sample.HelloWorld" version="0.1"><br /><name>Hello World</name><br /><initialwindow><br /><content>Hello.html</content><br /><visible>true</visible><br /></initialwindow><br /></application>

The HTML file (Hello.html) defines the user interface displayed when the application is launched via the AIR runtime. First, the JavaScript aliases file is included to make it easier to work with AIR classes. Next, the JavaScript appLoad function defines what happens when the application loads (function called by onLoad event of page).

The JavaScript function loads data from a simple text file via AJAX and places the text from the file in the HTML element with the ID called replace.

<html><head><br /><title>Hello World</title><br /><script src="AIRAliases.js" mce_src="AIRAliases.js" type="text/javascript"></script><br /><script type="text/javascript"><br />function appLoad(){<br />xmlhttp = new XMLHttpRequest();<br />xmlhttp.open("GET", "request.txt",true);<br />xmlhttp.onreadystatechange=function() {<br />if (xmlhttp.readyState==4) {<br />document.getElementById('replace').innerHTML = xmlhttp.responseText;<br />} }<br />xmlhttp.send(null)<br />}<br /></script><br /></head><br /><body onload="appLoad();"><br /><h1>AIR</h1><br /><div id="replace"><br /><p>Placeholder</p><br /></div><br /></body><br /></html>

Once the application is developed, the AIR command line tools can be used to package and distribute it. The AIR Developer Tool (ADT) creates installation packages, but it requires a digital certificate.

A simple approach

The AIR platform offers a great approach to building desktop applications. I love the fact that it allows me to use existing skills like HTML and JavaScript.

The AIR API offers additional functionality for building client interfaces. The API is JavaScript, so it is easily used within your application. While the qooxdoo approach is the exact opposite, I find the AIR model much more intuitive and easy-to-use. Everything necessary to get started with AIR is freely available online.

Leverage existing skills

A key point of AIR is the ability to port Web development skills to desktop development. Also, using Web technologies like HTML and Flash deliver a familiar interface to users, and developers do not have to spend time learning a new technology such as Microsoft .NET for thick client development. Another strong point is the cross-platform support that is not readily available in other development platforms. If you are interested in desktop applications, take a look at AIR.

The Web browser has evolved into the de facto standard application interface these days, but client applications are still necessary. Have you been faced with developing applications for the desktop? Have you taken a look at AIR?