Express all interfaces through objects

Almost all interfaces in the Taligent Application Environment are expressed as objects, specifically classes, which correspond to the abstractions that a developer must deal with. Interfaces should not be expressed by struct's, dictionaries, arrays, or any other kind of data structure. You can use these data structures in the interface (as function arguments, for example), but they can't embody the interface. Parameter blocks in the Macintosh" operating system are an example of a data structure that embodies the interface.

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.

[Contents] [Previous] [Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker