Login
Templates, Tools and Utilities
for Clarion Developers
Templates, Tools and Utilities
|
||
|
|
|
Icetips Article
Back to article list
Search Articles
Add Comment
Printer friendly
Direct link
OOP: Better OOP part 5 2003-04-19 -- Dan Pressnell Newsgroups: comp.lang.clarion,topspeed.topic.oop
March 5, 2006:
Note that the code is now available at:
http://www.icetips.com/downloadfile.php?FileID=59
We use Clarion to write database programs. (At least I do.) So it makes
sense to use objects to deal with data--record sets, single records, etc.
Not only is it a good idea to have objects "deal with" data, but it's a very
good idea to have objects CONTAIN data. For example, a TeamClass could
contain the data for Team records, as in the sample application I've
uploaded to http://toolwares.com/oop_sample.ZIP . If you have downloaded
that ans looked at it, download it again--I've made some additions.
Clarion's QUEUE structure is a nice feature of the language that looks very
much like a data file, or a database table. It has records and fields, just
like a data storage scheme. This makes it easy to enable classes to contain
data.
In the sample application, the TeamClassType and the PlayersClassType
classes do the chores of retrieving data from the database. But they go
further. You don't have to struggle with one record at a time when you use
the classes. Once you tell the class to "getdata()", your entire data set
is stored inside the class itself. As shown previously with the
TeamClassType, this provides maximum flexibility because the class can be
used anywhere in your program. Also, it provides maximum accuracy, because
once the data is retrieved correctly (you have fixed your bugs), you have it
working in every part of your program that needs the teams data set. It is
the QUEUE that makes this possible, classes can contain queues.
Putting a queue in a highly reusable class can present some problems though.
But those problems are easily fixed.
1. A class declaration cannot contain an in-place declaration of a queue.
It must contain a reference to a queue type, and that reference must be
assigned a queue instance with NEW in the class's constructor method. Also,
the queue must be DISPOSED in the class's destructor method. A few lines of
code and this is done. See the constructor and destructor code for the
TeamClassType class.
2. Because the class's queue can be used in many ways, having a fixed
structure (order of fields in the queue) requires some special handling.
See the PlayersClassType class in the sample application, and the
ShowPlayers procedure. The fields for the players list box are not in the
same order as the fields declared in the class's queue. But if you look at
the ShowPlayers code, you can see how easily that is fixed, by assigning
proplist:fieldno at runtime after the window is opened.
The advantage of using a queue (and getting out of the SET/NEXT/NEXT mode of
thinking) is that once your class has all the data, it is available
everwhere in your program, without having to define yet another VIEW
(Clarion view) for another browse, report, or process.
Also, with a queue holding a data set, your reduce the risk of corrupting a
record buffer when you are programming for one record at a time. Notice
that in the ShowPlayers procedure, which is called from the ShowTeams
procedure, there is code to potentially get a team record. Because this
data is held in an entirely different instance of the TeamsClassType class,
there is no risk of wiping out some record buffer on return to the calling
procedure.
It is not well enough known how powerful it is to process a queue structure
at run time. See the CsvExporterClassType class in the sample application.
That class will export any queue to a CSV file. And see the
GenericQueueViewer method in the GeneralClassType class. That method can
display in a list box any queue you feed it. (And notice how it has an
option to create a CSV file from the queue that is displayed.)
As you go through the code for the sample application, notice how small the
code is for the browses and reports. Also, notice that such code is
concerned only with instantiating classes and calling a few methods to
perform the data retrieval. Too many Clarion programmers think that Classes
equal "hand coding" (which is true) and think "hand coding" equals "too much
work" (which is false). If you use classes in your programs, you enhance
functionality, increase scalability, reduce bugs, AND end up coding less.
And that's a very good thing.
Dan
Today is April 28, 2024, 6:37 am This article has been viewed 35117 times. Google search has resulted in 136 hits on this article since January 25, 2004.
|
|