For the purpose of discussion within this document, an object-oriented application will be defined as one where data objects are the focus of the application. A data object is defined to be a particular representation of a logical data entity. For example, a document being edited may exist in two places: as an image in memory and as a file on a fixed disk. Each of these two forms constitutes a separate data object.
The procedures that operate upon these data objects in order to carry out application functions are encapsulated with the data objects to form application objects. Application objects are logically independent units comprising both data and function, which communicate with one another to request actions, conveyed in the form of messages passed between the communicating objects. In object-oriented terminology, the procedures that are invoked to carry out the required actions are known as methods.
Several rules apply to the design and behaviour of application objects. These are listed below:
As a corollary to the foregoing principle, the result of passing a particular
type of message may also vary, depending upon the type of application object
to which it is passed, and that object's interpretation of the message.
Adherence to this rule allows the behaviour of an object to differ, depending
upon the nature of the messages received by that object; this differing
behaviour is known as polymorphism.
For ease of processing, application objects with similar properties are grouped into object classes. Each object in a class is said to be an instance of that class. Application objects within the same class share properties such as data object definitions, class-specific variable definitions and values, and methods. Objects therefore take on the properties of their class; this is known as inheritance.
It is the concept of inheritance that provides a distinguishing factor between the two major schools of thought which exist under the object-oriented paradigm:
The primary advantage of the class-based approach is that it eases the task of defining object classes, since each new class belongs to a hierarchy of previously defined classes with their own properties and methods. The application developer therefore need only explicitly define the distinguishing characteristics of each class.
The major disadvatange of the class-based approach is the consequent high level of interdependence between objects. Since the unit of modularity is the entire inheritance hierarchy, rather than the individual object, reuse of a particular object presupposes reuse of all those objects in its hierarchy upon which the definition of the required object depends.
The class-based approach therefore provides a high initial productivity to the application developer, although with a consequent reduction in the level of granularity and an increase in run-time overhead.
The primary advantage of the module-based approach is that it avoids the object interdependence associated with the class-based approach, since each object class contains its own complete definition of properties and methods. Thus the unit of modularity is the individual application object.
The disadvantage of this approach lies in the fact that the application
developer is required to define each object class in its entirety, and typically
cannot rely on previous definitions. [This may be overcome to some extent
through subclassing, which is explained later in this chapter. ] The module-based
approach therefore attains a higher level of modularity and independence
between application objects, but at the expense of higher initial development
time.
The object-oriented approach to application design is most suited to applications where the data is the focus of the application, and is less suitable where the procedure or sequence of actions is the critical factor in the design. However, in mixed situations where only certain parts of an application or application system are procedurally oriented, as is the case with many work tasks, and where the provision of an event-driven user interface is desirable, the object-oriented paradigm can be extended to encompass procedurally oriented tasks. This is discussed further in Object-Oriented Applications.
While object-oriented applications deal primarily with the manipulation of data entities and their logical representations, there are many situations where an application must deal with other entities such as remote devices or systems. Administrative procedures defined by or imposed upon an organization may also be viewed as logical entities with which an application must interact. The incorporation of such entities into the object-oriented application paradigm requires an expansion of the concept of an application object to include the definition of and methods pertaining to any type of entity addressed by the application. This broadened definition is fundamental in making the object-oriented application model applicable to virtually any application scenario.