Understanding Object Systems

What are the terms and the differences between systems?

By Gary Odom, Foster City, California

Preface

This rather dry martini of an article presents a perspective about why object-oriented programming (OOP) is an important evolutionary step in programming practice, what the important issues are with object orientation, and a modest survey of object systems, with emphasis on C-based object systems.

It’s a Code Jungle in There

You’re writing a program in C / Pascal / Basic / Fortran. You add more data structures and functions as the program grows. Along the way, you find you need to change a data structure. To make the change, you need to track down all uses of the data structure within other data structures and functions. What a mess.

You’ve created a code bureaucracy. Each change involves a series of corrections in several locations, with potential side effects that need to be considered and dealt with.

Every program made with a procedural language becomes a code jungle. Maintaining the code jungle often involves taming some pretty hairy beasts. If you’ve worked on sizable projects, you’ve probably encountered some code written long ago that made you wonder, “how did this ever work?”.

The continuing challenge of software development is managing complexity. Structured programming languages, such as Pascal, came about in the early 1970s as an attempt to thwart the growing plague of Fortran and COBOL spaghetti code. Structured programming stopped the anarchy caused by GOTO, that notorious bad boy of programming instructions. The promise of structured programming was that the code maintenance crew could follow what was going on once the original developers moved on.

Programming practices have evolved with one primary motivation: improve the ability to maintain and reuse software.

Along with structured programming came the concept of code libraries: “code in the can” that could be reused on the next programming project down the line. If code could be made self-contained, or modular, it could be reused. While extra effort is required to make code general enough to be useful in multiple projects, the extra effort pays off over time.

Prefabricated Software

Object-oriented programming came about in an attempt to make code more modular and easier to reuse. The ideas behind object orientation are simple. To make code more modular, combine data structures and functions together: create software modules that are inherently self contained. In other words, prefabricate software so that code functionality comes in one piece. Each module becomes a class. A window class, for example, could be created to display and operate window objects on the screen.

To improve the ability to reuse software, allow classes to inherit from one another. This way, a new class can get all the functionality it needs from other classes, with the exception of the behavior that makes the new class unique. cWindow is the fixed size window class. A cWindow object can be drawn using draw, dragged using drag, hidden using hide, and so on. But a user can’t change its size. So, create a new class: cGrowWind, that has a grow box so a user can change window size. cGrowWind inherits all its behavior from cWindow, then adds one new behavior (or method): grow.

So, the two big concepts behind object orientation are 1) modular software components (by combining data structure and behavior), and 2) inheritance. While modularity, achieved through the use of classes, simplifies code maintenance, inheritance provides the sizzle of easy reuse by letting a programmer incrementally modify and expand class behavior.

Object Systems

Object orientation is implemented by an object system. Most often, an object system is built into a new language, or becomes an extension to an existing procedural programming language. Object-oriented language extensions almost always require a new compiler, though this is by choice, rather than necessity.

The success of any programming language is the ability to give a programmer range and flexibility in implementing software designs in the most straight-forward manner. C usurped Fortran and Pascal in popularity largely because C allows an programmer greater range (with such features as permitting a variable number of function arguments, and built-in bit twiddling) and flexibility in expression.

Inheritance

Because inheritance is one of the key concepts behind object orientation, one way to judge the quality of an object system is how flexibly inheritance can be specified. Multiple inheritance is the ability of a class to inherit from multiple classes. With multiple inheritance, a new set of methods (behavioral functions) can easily be added to an existing class. So, for example, you could attach a debugging class to another class without introducing new sequential links in the inheritance chain; the debugging class could verify the validity of data in objects of the target class. Most often, multiple inheritance is used to create a subclass that combines a class with primary functionality with another class that adds some ancillary characteristics. For example, a text graphic class (cTextGraphic) would inherit from a text class (cText) for text processing, plus inherit from a graphic class (cGraphic) to allow a user to treat the text as a graphic object (as in an object-oriented drawing program). Because it is so convenient, most current object systems support multiple inheritance.

An advanced object system allows inheritance and methods to be defined dynamically, while a program runs. This is called dynamic definition.

Class-Object Schizophrenia

The theory of object orientation makes a clear distinction between classes and objects. Classes are object factories, templates that exist only in source code. A class specifies object data structure, while a class itself has no data. A class just has methods, so that objects can take function calls. Objects alone exist as dynamic entities in memory as a program runs. An object can’t have methods separate from the class it inherits from, and a class can’t have its own data.

This fundamental distinction between classes and objects can be blurred to considerable benefit. Smalltalk and Objective-C allow classes to have their own methods (class methods), separate from the methods an object inherits from the class.

In an advanced object system using flexible class-object construction, classes may have their own data structure (class variables), and objects may have their own methods (object methods), separate from the class methods they inherit. These capabilities provide great flexibility in software design and implementation, as well as give conceptual consistency to working with objects. While theory may put a wall between classes and objects, eliminating class-object distinctions gives a developer great practical flexibility in meeting design requirements.

There is another aspect of object orientation that defines the quality of an object system: dispatch control.

Dispatch Control

Object orientation introduces a rather strange concept: calling a function without knowing exactly what function is going to be called. This happens because different classes can use the same function name. For example, to draw an object, you might write draw(self), where self is the object to be drawn. A dispatch mechanism is used to find the right method to call based upon the class inheritance of the self object. The technical term for this is polymorphism (Greek (to me) for “multiple shapes”). Polymorphism is great because it lets code become very general: you can draw all objects on a page by calling draw(self) in a loop, where the loop assigns self from a page object array.

Polymorphism necessitates finding the right class method to dispatch to at run time (dynamic binding), rather than binding a function call at compile time (static binding) (what linkers do for a living). Dynamic binding has two drawbacks. First, a dispatch error can occur if a method wasn’t defined for the function call made. Second, it takes time to find the proper method to dispatch to based upon class inheritance. Method dispatch is the overhead imposed by object orientation. These drawbacks are the price paid for quicker development time, smaller code size, flexibility in using prefabricated software, and easier maintenance. Hybrid languages, such as C++, let a programmer go back to procedural programming for time-critical code, whereas this is not an option with a pure object-oriented language such as Smalltalk.

Just as flexibility in specifying inheritance is important, so is flexibility in dispatch. Features of dispatch flexibility include being able to call multiple methods by a single function call, controlling which methods are called and in what order, being able to dispatch to a specific method, and dispatching based upon multiple arguments (called multi-methods).

The essence of high-quality dispatch in an object system is being able to call multiple methods in a single function call (multiple dispatch), and being able to control method call order (dispatch control). Imagine a resource-based picture class (cPicture), which inherits from a resource class (cResource). To draw a cPicture object (draw(picture)), you want to first make sure the picture resource is in memory. The cResource is used as a before-method, to check and load the resource if it has been purged. The cPicture draw method, which draws the picture, is an after-method.

An advanced object system allows dispatch control using before- and after-methods. A truly flexible object system lets dispatch control be altered dynamically, while a program runs, as part of dynamic definition.

Another aspect of dispatch control is being able to dispatch to a specific class method, rather than accepting the default dispatch. For example, you may want to draw just the handles on a graphic object by calling dispatch_to(cGraphic, draw, self), rather than calling draw(self), which draws an object and its handles. Almost all object systems offer this capability.

Multi-methods, which is being able to dispatch to a method based upon multiple arguments, is the object-oriented equivalent of a function being able to take variable arguments: you don’t use it often, but when you want it, the flexibility can’t be beat.

Object Links

One of the problems with procedural programming is that it takes effort to build self-contained, reusable software modules. But is it easy to link data structures through functions.

In a role reversal to procedural programming, the modular, decentralized nature of object orientation presents an interesting design decision: how best to link related objects. One challenge with object-oriented programming is designing the links between objects of different classes. Object links are the basis for object-oriented databases. Other than OOPC, described below, no object system known to the author provides built-in support for object links.

Object System Survey

Smalltalk

Dating back to the frosty beginning, from Norway in 1967, Simula was the first object-oriented language. But, because of its looming influence, Smalltalk is the grandmother of object-oriented programming languages. Smalltalk was designed as part of an object-oriented environment, with hundreds of classes, where everything is object-oriented. There is no class-object distinction with Smalltalk. Using the Smalltalk environment is a “deep immersion” experience in a land of objects, which is why it has been such an inspiration.

Smalltalk has a surprising limitation: it does not support multiple inheritance. Because even the simplest message uses dynamic binding (even the + in C = A + B), Smalltalk is slow. Smalltalk is also a memory pig, taking 2 MB of memory.

You may have read about “sending messages to objects”. The phraseology is a hangover from Smalltalk, where the syntax is object-verb (such as thisOval draw to draw thisOval), rather than the more typical function-calling paradigm of verb-object (such as draw(thisOval)). As with most languages, the verb-object function call model is used in this article. No message passing here.

clos

The Common Lisp Object System, known as CLOS, is the ANSI-standard language extension to Lisp that adds object orientation. CLOS is noteworthy because, in a sea of tug-boat object systems, CLOS is a luxury liner. CLOS supports multiple inheritance, dispatch control, multi-methods, flexible class-object construction, dynamic binding and dynamic definition. To simplify the application programming interface (API), CLOS consistently uses generic functions. Generic functions are polymorphic functions, such as draw and act. The object orientation that CLOS allows is tremendously flexible and expressive, but because Lisp has a limited domain, namely AI and list/language processing, CLOS, like Lisp, will never become a mainstream language.

C Object Systems

Because of its simplicity, flexibility, efficiency and range, C has become the industry choice for systems and application software development. It is natural to extend C into the object-oriented realm. A few interesting attempts have been made

Objective-C

An early attempt to make C object oriented was Objective-C. Objective-C adds Smalltalk-like object orientation using a strict superset of C. Objective-C adds a class definition mechanism, an object data type, and a message expression type. In Objective-C, each class is defined by two files: an interface file, and an implementation file. The interface file specifies the class programming interface: class and superclass names, along with instance variable (object) declarations and method declarations. The implementation file has class method code.

Objective-C supports multiple inheritance. Like Smalltalk, Objective-C permits class methods. Like C++, Objective-C provides ways to enforce data hiding and restrict method access. Objective-C lacks dispatch control or dynamic definition.

Included in the NeXT operating system environment is a set of classes written in Objective-C for application development. Because these classes are native to the platform, NeXT application development is relatively easy, especially compared to the complex nightmare of the Macintosh Toolbox. Objective-C is not available on the Macintosh.

Commercially, Objective-C was ahead of its time. Its corporate sponsor, Stepstone Corporation, was near financial death before being resuscitated by adoption for the NeXT line of workstations.

C++

C++ is a another language extension to C. Only part of the C++ extensions have to do with object orientation. Operator overloading, for example, adds flexibility to C, but has nothing to do with object orientation per se.

The object-oriented part of C++ implements a limited version of object orientation. Multiple inheritance is supported, as are class variables and optional dynamic binding, but C++ lacks class methods, dispatch control or dynamic definition. C++ classes have automatic initialization and deallocation methods.

C++ class constructs provide three levels of enforced information hiding. Access to data or methods can be private, protected or public. Restrictions can be overridden (by friend classes). The information-hiding features require new language syntax that complicates what was (in C) a lean language definition. Further, this feature sits in odd contrast to C’s celebrated openness with typecasting, data manipulation and the free use of function pointers.

The latest version of MacApp (3.0) is written in C++, providing a set of C++ classes for Macintosh application development. MacApp has been around since 1987, though previous versions have been in Object Pascal. MacApp has earned a reputation as being difficult to learn, but offers a full set of user interface classes.

OOPC

OOPC (pronounced “oop-see”) is an acronym for “Object Oriented Programming in C”. OOPC has an unusual implementation, in that it is not an extension to the C language, but rather a set of functions that turns C into an object-oriented language. Object-oriented programs written in OOPC therefore look like standard C code. This consistency with C simplifies learning and using OOPC.

The look and feel of OOPC, while simple, is deceiving. OOPC has all the features of CLOS: multiple inheritance, dispatch control, flexible class-object construction, and dynamic definition. Multi-methods can be simulated. Plus, OOPC comes with built-in support for object links and object-oriented database (OODB) development.

Like C++, OOPC provides automatic initialization and deallocation methods. OOPC also implements a form of garbage collection to prevent an object from being released while it is still linked to any other object.

Unlike Objective-C or C++, OOPC does not enforce data hiding or restrict method access.

OOPC always uses dynamic binding, but this overhead can be mitigated by creating a dispatch table, which essentially results in static binding while still allowing dispatch control options.

Although it has existed for years, OOPC has only recently been released to the public as a commercial product. The OOPC object system is only part of the product currently sold for Macintosh application development. OOPC includes a set of code libraries for rapid application development. Some low-level function libraries exist for efficiency and interface to the native operating system. OOPC also comes with a set of classes that provide automatic document management, application user interface, object-oriented database construction, and rule-based artificial intelligence.

To simplify the programming interface, the OOPC class library consistently uses verb functions. OOPC verb functions are the same as CLOS generic functions: verbs used as polymorphic functions. The consistent use of verb functions and a streamlined class architecture make the OOPC class library easier to learn and use than MacApp.

Below is a chart comparing the features of the three C-based object systems discussed. While all three support the basic features of object orientation, only OOPC is a full-blown implementation.

Feature Obj-C C++ OOPC

Multiple Inheritance Yes Yes Yes

Class Variables No Yes Yes

Class Methods Yes No Yes

Object Methods No No Yes

Multiple Dispatch No No Yes

Dispatch Control No No Yes

Dispatch Optimization No No Yes

Multi-Methods No No Yes

OODB Support No No Yes

Dynamic Definition No No Yes

Comparison of C-Based Object Systems