Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.object Subject: Re: Object-Oriented COBOL? Message-ID: Date: 15 Nov 90 18:50:48 GMT References: <679@dlogics.COM> <680@dlogics.COM> Sender: davidm@cimshop.UUCP Distribution: comp Organization: Consilium Inc., Mountain View, California. Lines: 52 In-reply-to: dsa@dlogics.COM's message of 14 Nov 90 22:13:47 GMT >>>>> On 14 Nov 90 22:13:47 GMT, dsa@dlogics.COM (David Angulo) said: > In article , [I] said: >> I kind of see this as a cost/benefit problem. Implementing the system >> using dynamic SQL would allow the system to grow more easily as new >> entities are added to the system, but the startup cost would be more >> difficult than static SQL to the individual tables. On the other hand, >> static SQL would make it easy to write functions like Class::insert(), >> Class::modify(), etc. for each entity (table) in the database, but, if you >> have a large number of tables, you'd eventually have a significant >> maintainance problem on the repetitious code when you need to make global >> changes (like changes in locking methods or table history). Sort of a "pay >> me now or pay me later" scenario. > 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. Yes! A very interesting question. Let me add to that: Given your statement: "You also need a Class::findMinimumSizeOf(size) to find all rectangles of a certain minimum size." as a requirement of functionality desired on an object corresponding to a database table, would you code this as a method against Class or as a method 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. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"