Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dlogics!dsa From: dsa@dlogics.COM (David Angulo) Newsgroups: comp.object Subject: Re: Object-Oriented COBOL? Summary: creating multiple methods of a class to access an object through SQL Message-ID: <681@dlogics.COM> Date: 16 Nov 90 22:36:49 GMT References: <679@dlogics.COM> Distribution: comp Organization: Datalogics Inc., Chicago Lines: 49 I wrote: If you just had to make a modify(), insert(), et. al. for each object, there would be no problem. What I am talking about is having to make many of these methods for *EACH* class depending on how you need to access that class. For example, in Ed Berard's rectancle class, you need a Class::findall() to find all of the rectangles. You also need a Class::findMinimumSizeOf(size) to find all rectangles of a certain minimum size. You also need a Class::findSizeRange (lowerSizeBound, higherSizeBound), ad infinitum. In article , cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > ... Would you code these as methods against Class or as methods > against ClassList?? The answer to this will help determine where your "many > methods" will reside and how best to express them. I "feel" that many of the > methods you would put on Class are relatively straightforward (perhaps even > *generatable* from the data dictionary in the database) while the methods you > would put on ClassList would be very specific to the application (foreign key > references *might* be a generalizable concept that would always be on > ClassList). In fact, Class methods might be best expressed using static SQL > while ClassList methods might be best expressed using dynamic SQL (you have to > evaluate this for each method). > > NOTE: these views are arrived at after having spent the last year going the > "easy" static SQL route. In hindsight, I think dynamic SQL might have solved > some tricky, *long-term* problems, but I haven't had the chance to prove it. Well, *THIS* is an interesting question. What I have done is to put each access method as a method of that class. Each one declares it's own cursor (stored as a class member variable) so that the destructor can clean these up (necessary in order to declare another cursor of the same name). Then, for each "access philosophy," I wrote a method to change the object's class member variables using the data from the next row found via the cursor. Thus, I also had class methods nextMinimumSize(), nextSizeRange(), and nextAll(), etc. I suppose you could put all of these methods in a container class and have the container class "new" a bunch of the objects. It's an interesting suggestion - I'll have to think about it. I don't see, however, how you could have these methods generated because there's no way *I* can think of to figure out which "access philosophy" (maybe SQL select criteria is a better term) you may want to use. There are infinitely many ways you could want to access them. -- David S. Angulo (312) 266-3134 Datalogics Internet: dsa@dlogics.com 441 W. Huron UUCP: ..!uunet!dlogics!dsa Chicago, Il. 60610 FAX: (312) 266-4473