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.
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.
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.
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.
The attributes of a class are bound together by the common agent, called Self....