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 Printed May 12, 2024, 10:49 am This article has been viewed/printed 35124 times. Google search has resulted in 136 hits on this article since January 25, 2004. |