fprintf, etc. Only the "methods" of the file object, fopen etc., access the members of FILE. The FILE functions are examples of good, modular, manageable code. A more accurate term for this type of programming is "structure driven". Structure-driven programs consist of data structures and functions that support them. The difference may only be semantic, but FILE objects don't have any allowance for inheritance or polymorphism. Structure members and functions that operate on them are not encapsulated into a single object. Adding More OOPness This article describes a technique which adds inheritance, polymorphism, and encapsulation to the familiar structure-driven style. The steps of this technique (listed in Table 1) are chosen to work with a particular implementation of inheritance. Consider the structures: struct s1 { int x; int y; }; struct s2 { int x; int y; int z; }; Suppose there is a structure of type s2 and a pointer to type s1. struct s1 *s1p; struct s2 s2s; s1p = &s2s; In almost all C compilers, s1p->x would be the same as s2s.x, and s1p->y would be the same as s2s.y. You could say that structure s2 inherited x and y from structure s1. Any function that expected a pointer to s1 could instead take a pointer to s2 and could correctly address x and y and safely ignore z. Listing 1 illustrates how to utilize this technique in an easy, self-documenting way. By using #define to define a class, S1, and using this definition to describe a subclass, S2, we assure that any changes to the S1_CLASS definition are automatically reflected in its subclass S2_CLASS at compile time. An object is an instance of a class. In Listing 1, C's typedef permits objects to be declared. Coding Conventions I observe certain conventions when writing methods for this OOP technique. The first argument to a method is always a pointer to the object calling the method. Many C++ translators do the same thing. The first argument to a method is always named this, clarifying references to the calling object. All program code for a particular class is always in the same .c file. Methods are given exactly the same function name as the pointers to those methods. These functions are static, so they don't interfere with other functions of the same name in other files. When writing an abstract base class's methods, write functions for methods that are defined to be subclass implemented. You may simply print a message to the effect that the method is not available. All constructors are named in the form new_CLASS(). The only arguments in constructors are for initialization. The template in Listing 2 is the basis for all constructors. If the constructor is a base class, remove all SUPER_CLASS references from this template. Destructors have a format that reverses the inheritance process. Destructor names have the form destroy_CLASS(). The first, and usually only, argument is a pointer to the object being destroyed. The second template in Listing 2 is the general form of a destructor. Prior Art Eric White described another technique for writing "truly" object-oriented programs in the February issue of The C Users Journal. There are some differences between the technique I am suggesting and his. This technique does not require any data structures other than those required by the objects. There is no specific CLASS structure and no specific OBJECT structure like in White's technique. This technique does not require the use of any additional functions such as White's message function. Classes and subclasses are defined using C's #deine directive. Methods are inherited from superclasses in a subclass's constructor, like White's, but no function is required to register new methods. There are no separate constructors and destructors for CLASS and OBJECT. Constructors and destructors have more responsibility for inheritance and polymorphism. Scope is used to supply a rudimentary form of polymorphism, an issue not directly addressed by White. The resulting syntax of this technique is closer to C+ + than White's. Compare the following three object-oriented methods of having a circle draw itself. The first example is C++, the second uses White's technique, and the third uses the technique described here. 1. circle.draw(radius); 2. message(&circle,DRAW,radius); 3. circle->draw(circle,radius); This similarity to C++ was important to me. Most of the OOP code I have seen in articles has been in C++, and I did not want to have to make a large mental jump to get from C+ + to code I could use. An Example Application Many applications need to deal with lists. Sometimes these lists are arrays, sometimes they are linked lists, some- times they are views of database records. This example will develop a LIST_CLASS. The goal is to create a class that will allow an application to have uniform access to all types of lists, without the programmer having to concern himself with how the list is stored. I developed this object when I needed a selector window. The selector window is used as a menu and chooses a record from a data table. The SELECTOR object had a LIST pointer as a member. Concrete sub-classes of ARRAY_LIST_CLASS and PINNACLE_LIST_CLASS were both used by the SELECTOR, fulfilling the 00 requirement that a subclass can be used in place of a superclass. I chose the Pinnacle library for two reasons. First, it is a good, modular, "structure-driven" library. I was able to add an OO layer to it by encapsulation. The second reason is availability. Pinnacle is a commercial product, but a free trial disk is available from Vermont Database Corporation. The trial diskette will suffice if you want to try these programs yourself.