Advertisement

Object-oriented APIs are toolboxes for programmers. An API contains types and their members: classes to instantiate, classes to subclass, interfaces to implement, constants to use, and static methods to invoke. When you design an API, you design types. But the main utility of those types is providing client programmers with useful objects they can employ in their programs. The primary tool an API toolbox offers is objects.

To be a good API designer, therefore, you need a sense of what makes a good object design. In this chapter, I discuss a handful of object designs that I feel are fundamental. If you like big words, you can consider this chapter as a taxonomy of objects, a way to classify objects into categories such as service, messenger, performer, value, immutable. My goal for this chapter's material is to give you a feel for different kinds of object designs and the situations in which they are appropriate.

Guideline 1. Design objects for people, not for computers

The basic conceptual unit of object-oriented design is, not surprisingly, the object. It is therefore vital that designers of object-oriented APIs grasp the significance of the object. To me, the most important thing to keep in mind when designing objects is that objects are for people, not for computers. When you design objects, you should think primarily about the people who will use them.

The point of objects is not to help computers run software, but to help people develop software. Computers are just as happy running assembly language programs as object-oriented programs. But people are more productive (and with luck, happier) writing object-oriented programs. The main aim of software technology advances, from machine language to assembly to procedural to object-oriented languages, has been to help programmers do their jobs. In particular, objects help programmers manage the challenges of software complexity and change.