Express all interfaces through objects

Avoid using global variables or functions in an interface. Global variables that are really constants are exceptions, as are overloaded operators; for symmetry, the latter must sometimes be global friend functions rather than member functions.

Functions should be members of some class: either regular members, if they can be characterized as an operation on some object, or static members, if they don't apply to one object in particular.

Avoid objects or classes that do not correspond to concepts the developer must deal with. A common example is classes whose name contains "Manager" and of which there is only one in a given application or task. These are really modules that have been turned into classes (see "Modulitis" on page 50); they do not make good objects. Usually, their member functions should be dispersed among other classes, either as regular members or as static members. If you have an object that communicates with a server, the object should not be visible in your interface: the existence of servers should never be visible in class interfaces (except for those used to implement servers).

Avoid using types that are not objects to represent abstractions that should be objects. One good example of this is ID types; other examples from the Macintosh OS include refNums and resource IDs. The problem with these ID types is that they represent an abstraction, but there is no object.

In the Taligent Application Environment kernel interface, task IDs are replaced by task handle objects. It's still possible to get the task ID for informational purposes, but it has been supplanted by the object as the primary identifier. Similarly, the Window Server uses unique IDs to identify system windows internally, but these IDs aren't visible in the client interface to the Window Server: instead, the client creates system window objects.