OO COBOL: Client Programs

Either an ordinary program or a method definition may use objects. The syntax is almost the same in either case.

IDENTIFICATION DIVISION

Nothing special here. An ordinary program has a PROGRAM-ID, and a method definition has a METHOD-ID, as usual.

ENVIRONMENT DIVISION

Any program which uses objects must have a REPOSITORY paragraph in the CONFIGURATION SECTION, declaring all the classes used:

 REPOSITORY. CLASS Foobar IS 'Foobar'.

For a method, the REPOSITORY paragraph belongs in the class definition rather than in the method definition itself.

DATA DIVISION

You can't declare an object directly in the DATA DIVISION. Instead, you declare an object reference to it:

 01  GENERIC-OBJ           USAGE IS OBJECT REFERENCE VALUE NULL.
*
 01  FOOBAR-OBJ            USAGE IS OBJECT REFERENCE Foobar VALUE NULL.

In the example above, GENERIC-OBJ is a universal object reference. It may refer to any object. FOOBAR-OBJ, however, is restricted to objects of the class Foobar, or of classes derived from Foobar. In each case the VALUE clause initializes the object reference so that it doesn't point to anything.

Object references may occur in the WORKING-STORAGE SECTION, the LOCAL-STORAGE SECTION, or the LINKAGE SECTION. Presumably they may appear in the FILE SECTION as well, but not usefully. Like a pointer, an object reference is meaningful only during a particular execution of the program.

PROCEDURE DIVISION

Invoking Methods

The only way to use an object is to invoke one of its methods:

     INVOKE FOOBAR-OBJ 'displayOnSysout' USING INDENTATION-DEPTH.

I won't try to list all the possible variations. Suffice it to say that an INVOKE works much like a CALL, and offers pretty much the same options, except that you have to provide an object reference to identify the object whose method you are invoking.

Depending on compile-time options, the compiler may optionally consult the Interface Repository (IR) to verify that you are passing the right kinds of parameters to the method.

Attaching References to their Objects

By using the SET verb, you can make one object reference refer to the same object as another object reference:

     SET GENERIC-OBJ TO FOOBAR-OBJ.

You can also detach a reference from its object:

     SET FOOBAR-OBJECT TO NULL.

Within a method definition, you can attach a reference to the object whose method you are defining:

     SET FOOBAR-OBJ TO SELF.

Creating and Destroying Objects

Declaring an object reference does not create a corresponding object. You must create every object explicitly by invoking the somNew method:

     INVOKE Foobar 'somNew' RETURNING FOOBAR-OBJ.

At first glance, this syntax appears different from the kinds of INVOKEs described above. You can't specify a Foobar which doesn't exist yet, so you specify the class instead.

Actually this syntax is less different than it appears. Foobar is an object. It is an instance of the class SOMClass (which is an instance of itself). The method somNew is not a method of Foobar -- it is a method of SOMClass. The real difference is that we don't need an object reference to the Foobar class. The REPOSITORY paragraph serves the same function instead.

When you're through with an object, you should destroy it:

     INVOKE FOOBAR-OBJ 'somFree'.

This time you specify the object, not the class.

Special Methods: somInit and somUninit

Whenever somNew creates an object, it invokes the somInit method, which is intended to initialize the object. It first invokes somInit for all the base classes, from the top down, and eventually invokes the somInit for the last-derived class, if one is defined.

Unfortunately somInit accepts no parameters. Left to its own devices, it will initialize each instance of a given class in exactly the same way. In practice you generally want to initialize different instances differently. It's up to you to come up with a way to do so.

When somFree destroys an object, it invokes the somUninit method for the last-derived class, if one is defined. Then it invokes the somUninit methods for all the base classes, from the bottom up -- in the reverse of the order in which somNew invoked the corresponding somInit methods.

You are expected to override somInit and somUninit as needed. In particular, somUninit provides a way to automatically release any resources which may be associated with an object -- such as files, dynamically allocated memory, or other objects.

Cobol Home

OO Cobol