Contents of the READ.ME file
The other day, I wrote a simple DOS-file-to-.DBF data-conversion utility
for a client in Clipper 5.01, using Funcky for the ASCII file I/O. I
then downloaded OCLIP 1.0a, the latest version of the FREEWARE
object-oriented extension to Clipper 5.01, and rewrote the utility to be
object-oriented just to evaluate OCLIP. I produced three sets of source
files that solve my problem using three slightly different methods.
Then I measured the execution speed of each method. Below, I outline my
problem and solution, briefly describe each method, present the test
results, and list the files.
The source files are made available to show what the object-oriented
counterpart to a traditionally coded, real-world program looks like.
This is my first stab at OOP in Clipper; however, I have written large
and small systems using OOP. I've done OOP programming in C++ and C
(yes, C), and I've played around with Smalltalk V/286. I haven't
agonized over the code, so it may be a little ragged. Any comments are
THE PROBLEM AND SOLUTON
The client is presently able to print medical-claim forms with their
existing back-office medical system. They are able to direct the output
to a DOS file. The product we sell wants the same information, but in a
dBASE file. An additional problem is that each one-page form can
contain from 1 to 6 entries for services rendered, with each service
resulting in a record being written to the dBASE output file--there is a
one-to-many relationship between forms and dBASE records.
A custom utility that we write can convert the forms in the DOS file to
a dBASE file. Since we'll probably have to do this type of conversion
for other clients in the future, it would nice to make the code easy to
The first is traditional, non-OOP. All code is in one file.
The second is a hybrid. Code is separated into files according to the
"class" it serves. This is not "object-oriented," "class-based," or
"object-based," to use Dr. Peter Wegner's classifications. It's just
maybe a little better organization of the code; for that reason, it's
not that interesting.
The third way uses the same code separation as the hybrid, but it is
object-oriented. Using OCLIP, four classes are defined: Boolean is for
logical objects, DOSFile is for DOS ASCII files, Form is for
medical-claim forms, and XYZForm is a specialization of Form. The
DOSFile and Form classes contain a Boolean object as an instance
variable. The Form class also contains a DOSFile object.
Boolean and DOSFile are foundation classes that any basic class library
should contain. These should be more robust than what I'm presenting
here. For example, there is no write-record method in DOSFile because
my little program didn't need to write to DOS files. The missing
methods are easily added. Boolean is probably overkill, but I
thought... what the heck. Form is an abstract class of which no object
should be instantiated (created). It is merely intended to be used as a
superclass. A "template" class, so to speak. XYZForm is a subclass of
Form. It is a medical-claim form used by a particular "XYZ" health
There should clearly be more classes in my program. For example, .DBFs
are not represented by a class. Like DOSFile, this should be included
in a basic class library. As I said, this is an exercise in evaluating
OCLIP and OOP in Clipper in general, not in building a robust class
hierarchy. I would hope to _buy_ my foundation classes.
THE TEST RESULTS
The ASCII input file is 816K. It contains 544 forms, with an average of
2 medical-services entries per form. Each service results in a record
being written so that 1089 records are written to the .DBF. The output
.DBF ends up being 94K. The tests were run on a 20Mhz 386DX clone with
all disk caching turned off. The machine was warm-booted before each
test. .EXE load time has been subtracted from the numbers. Time is in
Method Execution Time % Degradation
Object-oriented 2.66 - -
Hybrid 2.08 = 34
Traditional 1.98 - -
Degradation occurred from traditional to hybrid to object-oriented.
Just so you don't misread my chart.
I'm sure a lot of time was spent doing I/O, so an object-oriented
CPU-intensive program would experience greater degradation over its
traditional counterpart. But who writes those kinds of programs in
This is a list of the files that are zipped together:
read.me This file