Oops With Foxpro

Object Orientation In FoxPro

Editorial Note:

This article was written by Gregory L. Reichert and uploaded to the CompuServe Fox Forum on the 19th January 1995. The text remains unaltered although I have taken the liberty of tidying up the code samples. The casual Web surfer should be warned, there\\\'s some pretty complex stuff here.

Malc.

Introduction:

Object Orientation Programming in FoxPro? Yes. The OOPs technique is not an alternate form of programming, but am extension of Structure Programming. Much the same way that structure programming inherits commands and features of unstructure languages like BASIC and Assembler, OOPs should inherit structure programming languages features. The general notion is to enhance the programming style, and still maintain backward compatibility. In the case of implementing OOPs into FoxPro, this should be a rule. The technique I about to describe is simple and requires no external modules. The implementation uses straight forward fox features, and allows greater flexibility then found in many of the other object orientated languages.

Background:

Recently there has been a lot

of talk about Object Orientation, but until Nantucket announced Clipper 5.0, there has been no evidence of it finding its way to the xBase dialects.

But before we jump into how to construct and using object, let\\\'s determine what a object is. The world is full of objects. Everywhere we look, we find objects. These objects are described by their characteristics and behaviors. The same definition applies to software objects. For example, take a book of matches, it can be described to a computer as something of X width, Y height, containing Z items, and etc. This does little to help define what the matches really are, it simple describes the characteristics, but does nothing to describe its usage or behavior. A set of separate routines need to be designed to implement the matches usage. Currently, FoxPro offers little means of binding the routines with the associated data, outside of the routines dependency on the data.

Encapsulation:

This is where objects come into play. They offer a method of Encapsulating, or binding the routines with the associated data. Within a software object are defined the characteristics as a set of data variables. The matches behaviors are defined as Methods, or variables containing the names of routines that manage the data. Like actors on a stage, we simply request from the object to perform one of its services, and the object acts out the predefined operation using the associated data. In respect to the Matches concept, we could have defined some methods like: REMOVE, LIGHT, BURN, PUTOUT to describe to basic activates. These methods would manipulate the data variable REMAIN, the remaining number of matches.

After some common-sense investigating, we discover that the feature of Encapsulation has been a concern of programmers all along. In most applications, the code and data are viewed as related entities; where the code goes, the data follows, and vise-versa. In this case, the needed binding agent is missing. Leaving the responsibility of keeping them together up to the programmer\\\'s memory, not the computer\\\'s.

Objects definitions resolve this dilemma. As mentioned, they offer a common, but unique, binding agent to maintain the relationship between the code and the data it effects. Objects and their binding agent can be thought of a containers that group data with its related code. Normally, we refer to these containers as Classes. A Class is a logical definition, while an Object is physical, a working representation of the Class. In principle, there is one, and only one, Class definition, but many Objects can be generated from that Class. From this point on, the term Class will refer to the structure of the object, and Object to the run-time representation the class.

Self:

The attributes of a class are bound together by the common agent, called Self. It serves two purposes, first being the binding agent, a unique entity shared by all the attributes of any single class. Second, it acts as the objects identifier, or the Instance of a Class. We address an object\\\'s attributes with use of Self. Every class attribute is declared, accessed, and released with respect to the self reference.

Inheritance:

At this point, we have devised a method that enhances reusability, or the ability to port various portions of one application to another. Object orientation doesn\\\'t stop there, but includes many other enhancements. Object classes can expanded to incorporate new features without modifying the existing code or data. This concept is called Inheritance. For instance, take our Matches example, matches serve their purpose well, but only to a limited degree. Only twenty attempt can be offered, and a strict environment control need to be observed. We can improve on our situation by purchasing a disposable lighter. The lighter perform all the function of the matches, plus insures greater number of lights, and better durability. In a sense, the lighter inherits all that attributes of the matches, improving on it\\\'s weak areas, while maintaining it\\\'s strong points and purpose. This is important in designing software object classes.

The matches still exist, but now we have a lighter. In computers, this translates to an easier and natural method of Version Control. As the application evolves through it\\\'s versions, the previous versions remain intact deep inside the current. By instigating the object that defines a previous version, the application performs that version as if the enhancements where never included.

Polymorphism:

The previous version of a class is the parent to the new child class. In fact, a parent class can spawn many variations of child classes. This multiple offspringing is referred

to as Polymorphism, meaning Many-Shapes.

Polymorphism can be observed in the Matches/Lighter example, if we first suggest that disposable lighter is a child to a class of flint/steal igniters. Flint/steel class offers the basic concept of any lighter, without defining any one type of lighter. Not only can the disposable lighter be defined from this base class, but we could also derive a ZIPPO-type of lighter