Hi Allan, I followed this as well - interesting discussion.
Again at the risk of offending, it might not hurt to revisit some old concepts to see where you are with them. OOP boils down to simplification - write one - use many, we all say. And this true. Objects can be anything we want them to be but all are based at some point on primitives. Procedures are objects in much the same way as a database is one too. Procedures can be abstracted and used as arguments for yet other procedures. Likewise data can be abstracted. A CD collection, for example can be stored in lots of ways and each has advantages and disadvantages. Throw a stack of CD's into a box and you still have a collection of CD's. It has properties: unsorted, in a box, my CD's, etc. It's easy to just throw another CD into the box but it is difficult to get a particular CD from the same box. If you sort the CD's in alphabetical order by Artist it takes a bit of effort. Getting a particular CD is a snap ... it's order. Placing a new one into the stack is a little bit difficult because it has to conform to the property for the CD stack: ordered by Artist. Each of these is a data abstraction and we deal with such things all the time. And if you think about it procedures can be used as part of the data abstraction - a model of whatever it is you are doing. A procedure can be passed as an argument (all functions and procedures resolve to something). Occasionally though it's helpful to get back to the basics to ensure that our understanding of some of the fundamentals is correct because if it isn't then logically, choices we make based on faulty beliefs or understanding may themselves be flawed: a cascade. DELPHI is very good at what it does. One of the significant advantages of the language is that it allows us to step back and deal quickly with quite complex concepts as opposed to get down and dirty to create them ourselves. Based on what you are able to do I am hesitant to suggest you lack skill because I would be wrong. However, I really would encourage you to go over data abstraction / procedural abstraction and then move forward onto OOP. Deficits in these fundamentals might cause ongoing difficulties for you. The problem you presented (like most things) can be approached many ways. Choosing which is most suited for a given task is part of the challenge of programming and problems solving. My two cents worth is a recommendation for you to explore the basics of programming: recursion, iteration, abstraction (data and procedural), messaging, dispatching etc. It won't take long. If you bed these things down then you will be better placed to apply the skills you have more effectively, a little revision = lots less effort and much more robust solutions that require minimal effort to maintain. I'm conscious that my suggestion may appear to be me projecting my issues onto your own and others are here to ensure any 'bad' ideas are challenged (no offence taken to any BTW). I noticed that by doing this myself ( a refresher I guess) I really improved my grass roots understanding of the science and my solutions were much more robust. Like I said, just my two cents worth. IT really is a lot of fun - and you are quite correct in acknowledging the support that others on this list offer to others. I've always valued their input far higher than I might a textbook. Each is valuable. One is dynamic and offers new opportunities to challenge ourselves - peer review. Good luck. Mike ----- Original Message ----- From: "Alan Colburn" <[EMAIL PROTECTED]> To: "Borland's Delphi Discussion List" <[email protected]> Sent: Wednesday, May 23, 2007 3:00 AM Subject: Re: OOP -- Persisting Lists [op] > Hi folks -- > > My thanks to all four of you for your responses. I found them particularly > interesting to read together, in that it seems like they represent > alternate > ways of looking at the same problem. Some seem to start with the objects, > and some with the databse fields. I admit my knowledge of both databases > and > OOP are somewhat elementary (I've never needed DB's beyond "MyBase" style > ClientDataSets, for example). I find data aware controls simplify > programming (an advantage), while simultaneously encouraging me to program > by writing a whole bunch of event handler code in Form1, rather than > breaking my work up into logical classes (a disadvantage when I come back > months later and want to change the program). So, as a way to teach myself > to be more "OOP-ish" I'm working on rewriting some simple things I've done > in the past. I tend to end up with the same problems when trying to divide > everything into nice, neat classes-- > > --problems related to sending information between classes, > --problems trying to decide where to put properties and methods relevant > to > two or more classes (e.g., employers have employees, and employees have an > employer), and > --problems related to saving information. > > I posted several times last summer related to the first issue, and got > some > great responses back that helped me. I think the second point I'll > continue > to learn about, but it's at least part of the art & decisions of object > oriented programming ... and now I've got things to think about related to > the third point! > > Thanks for your help, as always -- Al > > _______________________________________________ > Delphi mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi > > ---------------------------------------------------- > This message has been processed by Firetrust Benign. > _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
