The notion of object classes, and the extent to which this concept is taken, provides the distinguishing factor between two primary schools of thought within the object-oriented paradigm. Under a class-based approach, objects are defined in terms of their class, and each class is defined in terms of other previously defined classes, the properties and methods of which are automatically conveyed upon the new class; this is known as the principle of inheritance.
For example, the object class "horse" may be defined as a sub-class of the object class "quadruped", with the additional properties of being able to be ridden and eating grass. A further object class "pony" may then be defined as being a sub-class of the class "horse", with an additional upper limit on size. While this is a somewhat frivolous example, it illustrates the principle that an object class is defined in terms of other object classes, and need only explicitly define those properties and methods that are unique to that object class. All other properties and methods are inherited from its parent class or classes. This introduces the concept of an inheritance hierarchy, in that an object inherits not only the properties and methods of its class, but also those of other classes by way of which that class was defined.
The major advantage of such an inheritance hierarchy is that, given a well-documented set of existing objects, it becomes extremely easy to create new object classes, simply by defining the new class in terms of other classes that already exist, and simply specifying any new or different properties or methods that apply to the new class. This of course assumes the use of adequate object documentation and management practices. Without such practices, it becomes difficult if not impossible to identify a suitable base object from a large library of existing object classes.
However, many existing implementations of the class-based approach extend the inheritance hierarchy to a great degree, such that almost all imaginable object classes are defined in terms of parent object classes. While this provides a unified approach to the problem of object definition, the significant disadvantage of such an approach is the increased level of interdependence between objects. The unit of modularity becomes the complete hierarchy rather than the individual object, since an object has no complete definition in its own right. The reuse of a single object therefore requires the inclusion of its complete parent hierarchy. Since it is typical for this parent hierarchy to be defined dynamically using run-time definitions for parent classes rather than defined statically at application generation, it is also possible for changes to a parent class to cause unforeseen side-effects in the behavior of descendant object classes. Thus inheritance hierarchies require careful management to ensure that such side effects do not occur and adversely affect the integrity of applications and data.
Where the inheritance hierarchy is taken to the extent of providing system-defined object classes, to which all application-defined object classes are linked, the hierarchy and thus the application is dependent upon the existence of a virtual machine conceptual environment, which must also be accepted along with the hierarchy. This in turn may result in significant penalties in terms of application efficiency and run-time performance.
A module-based approach to object-oriented programming defines each object as complete in its own right. Objects may still be grouped into classes for easier definition and processing, but each class possesses its own complete set of properties and methods, and is not dependent upon another class for a part of this definition. The primary advantage of the module-based approach is the increased level of independence between objects, with a finer degree of granularity in the application allowing object reuse with a lower level of overhead. The main disadvantage of this approach is that each object class must be completely defined, requiring more work on the part of the application developer at the time the object is created.
The concept of inheritance, while providing great potential for productivity enhancement during the application development process, must be carefully managed in order to avoid additional complications in application management and maintenance due to object interdependencies. Side effects arising from modification to parent object classes may adversely affect the integrity of an application. The alternative course of action, that of prohibiting the modification of existing objects in favor of creating new objects that inherit only the unmodified properties of the existing object, is often not viable due to the increased application overhead and managerial effort required to maintain and control an ever-expanding inheritance hierarchy. Reliance on the behavior of existing objects must therefore be viewed with extreme caution in the absence of effective management controls over object modification.
The increase in development productivity provided by the use of inheritance may often be offset by the increased time and effort spent in regression testing of existing applications in order to determine any effects on these applications caused by the modification of existing object classes. Tight managerial controls over development must therefore be maintained in order to identify and isolate those existing object classes that are modified and which are likely to affect existing applications.
One technique that can be used to minimize the impact on existing applications is for the development organization to adopt a standard whereby, once an application object is deployed in a production environment, new applications that use the object may only modify its behavior through the use of subclassing (see Subclassing). This means that the object itself is not modified, and other applications that use the object are not affected.