Sponsored Link •
This article suggests that good API designs happen when designers think of objects as machines, classes and interfaces as blueprints for those machines, and client programmers as users.
Objects are invisible machines that programmers use as tools. When you design an object, you design a machine for programmers. I feel thinking of objects as machines is helpful, because it encourages you to focus not only on functionality when you design objects, but also on usability.
The two main qualities I look for in any machine are functionality and usability. If I buy a new cyclometer for my bicycle, for example, I want that cyclometer to work well—to reliably keep accurate time, distance, and speed records. But I also want it to be easy to use. I want services I request often, such as switching the display between distance, time of day, and speed, to be quick and easy to access. I don't mind if less-used services, such as setting my tire size or the current time, are more difficult to access. But in no case do I want to invest more than a few minutes of my time pressing buttons or consulting the instruction booklet to access any functionality offered by my cyclometer.
Similarly, if I instantiate a class in an API, I want the resulting object to work well. I want the object to do what it promises to do, in an efficient manner, every time I ask it. But I also want the object to be easy to use. I want its interface to allow me, with no more than a few minutes searching through the API documentation, to figure out how to make the object perform the desired service.
People build machines to provide services to other people. By machine, I mean any kind of tool made by people for other people to use. Pencils, hammers, chairs, stamp dispensers, televisions, bicycles, buildings, and space shuttles are all machines in this sense. So are software applications such as word processors and accounting programs. And so are objects. Objects provide services to people who happen to be programmers.
Given that machines are created to provide services to people, every machine has a means by which people can use it, its interface. A hammer's interface is its handle. A stamp dispenser's interface is its buttons, knobs, and displays. A word processor's interface is the menus, toolbars, and dialog boxes of its graphical user interface (GUI).
An object's interface consists of some combination of constructors, fields (usually constants), and methods. These are the buttons, knobs, and displays that allow people to use the object. In the case of objects, the users are a particular kind of people, programmers, who are trained in the use of constructors, fields, and methods.
A class is not a machine. A class is a blueprint for a machine. The object is the machine. To create an object, you feed a class, the blueprint, to a computer. The computer creates the object from the blueprint automatically. Because objects exist only inside computers, people never use objects directly. Instead, people use objects indirectly by writing code. This is why object users are always programmers—to use an object, you must write code. Your code uses the object directly on your behalf.