Object-oriented application design places the focus of an application on the logical entities or objects (typically items of data) upon which a program will operate, and attaches procedures or routines to manipulate these objects. A logical data entity (such as a group of records) may have multiple representations within the system. Each of these representations is known as a data object, and each data object may have a finite set of actions performed upon it. The data object itself, along with the routines (known as methods) used to perform these actions, are together regarded as an application object.
Note that in the remainder of this document, the term data object will be used to denote a particular representation (for example, on the screen or in a disk file) of a logical data entity. The term application object will be used to denote the conjunction of a data object and its methods. While these terms are not in general use, they will be used here in order to provide a distinction between a data item, and the conjunction of that data item and the routines that act upon it.
Application objects typically respond to events, which originate outside the object and which may be system-initiated or user-initiated. The sequence of these events determines the sequence of operations within the application, and the progression of dialog between the application and the user, rather than the application determining the sequence of the dialog, as is traditionally the case. Such an object-oriented application environment is thus said to be event-driven.
Events are communicated to an application object by means of a series of defined messages, which are not considered to be part of the objects between which they are passed. The focus of the program thus becomes the object, rather than the procedure, and the program becomes a flow of messages between cooperating objects.
Actions on a data object should be possible only by sending messages to the associated application object; an object's methods should not be directly accessible from another object, nor should the behavior of an object be dependent upon any external source other than the messages it receives. A message should also specify only the action that is to be carried out, and not the way in which it is to be accomplished. It is the responsibility of the receiving object to determine the way in which to carry out a requested action. Consequently, the behavior of an application object may differ, depending upon the class and content of its input messages. A corollary of this statement is that the result of passing the same message class may vary, depending on the target object class and its interpretation of that message. These guidelines outline the concept of polymorphism.
One of the primary properties of an application object is its modularity; objects that obey the foregoing rules should be largely independent of one another, and the implementation of one object should not be dependent upon the internal details of another. Data belonging to an application object should be accessible only by that object; requests for access by other objects should be made via appropriate messages sent to the application object that "owns" the data object. Thus the only information necessary to use an application object is a knowledge of the messages it can receive and operate upon (through its methods). This rule encompasses the principle of encapsulation, which states that a data object should be defined, created and/or accessed solely from within its "owner" application object.
Since a number of application objects may exist with similar characteristics, such objects are usually grouped into object classes. A class consists of those objects that share similar properties and methods. An object class is typically associated with a single data object or type of data object, and has a defined, finite set of methods associated with it. It is the class that normally defines the messages and methods applicable to an object. Each object belonging to a particular class is then known as an instance of that class. Each instance inherits data objects and values defined for its class, and may also contain its own data, known as instance data; the properties of instance data are typically obtained from the definition of the object class, but the values are defined uniquely by each instance.
The object-oriented approach is most suited to situations where the purpose of the application is the manipulation of data, whether on the screen or in a data file, and where the exact sequence of actions is not critical, provided all necessary actions are carried out. The focus of an object-oriented application is the data objects that are being manipulated; the functions to be performed are subordinate to the data objects upon which they will act. In addition, the event-driven user interface places the user in control of the sequence of actions, and provides flexibility with respect to the way in which the desired result is achieved.
An advantage of the object-oriented design approach for data manipulation applications is that a particular data object is "owned" by one application object, and that the definition of and establishment of access to that data object is achieved from within the application object. Since application objects may be made relatively independent of one another, other objects may be isolated from changes to the data structure. This greatly simplifies application maintenance, since all necessary changes need only be made within a single object.
Note that since application objects are closely related only to their associated data objects, and not to the applications from which they are accessed, it follows that application objects may be constructed for each data object, and accessed from multiple applications. An application need not be aware of the internal workings of an application object, but need only know the correct type and format of the messages through which to interact with the object. Thus the object-oriented approach facilitates code reusability.