Thanks, John, I'm not sure I completely get the idea of a pair class. As an question and answer are in the same database tabel I now created a questionDepot class that gets the array from the db, does save and update operations, and for example, sets a flag in the db tabel when a question is accepted for the list.
My question was asked with the experience that a complete procedural approach often turns out to become messy, you have to use certain visual objects more often in teh app, therefore why not create a visual class to use more than once. So, it was just an urge to write cleaner code .... By the way: as always, I already exceded the 3 or 4 pages David mentioned, if only for the idea to add a 'placed' tag in the db. Sjef ""John Wells"" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > On 6/29/06, Sjef <[EMAIL PROTECTED]> wrote: >> Hi there, >> > Hi Sjef, > > First off, I think David has a good point with regards to the OO vs > Procedural approach. If you're looking to do this quick and easy, it > might not be worth your time fussing with OO. Unless you'd like to > just for the exercise, which I wholly support, so go for it! > >> I want to create a class Question for dealing wiht the questions and a >> class >> answer for the answers. Each could contain an array with the their part >> of >> the content of the database table. > > As far as how to design it OO-style, I'd first urge you *not* to have > separate classes managing lists of questions and answers. Say for > example you query your db for questions, build up your array inside > your questions class, and then while doing the same for your answers > class, you inadvertently introduce a looping bug that drops one of the > answers from the array, or possibly changes the order that you create > your array, or any other number of possible mistakes (human or > otherwise). > > Point is, in the end you'd have two out-of-synch classes that really > should've been built separately to begin with. A single question and > it's answer(s) are tied together, so keep it that way in your class > abstraction. > > That said, I'd suggest building a question-answer *pair* as a class, > and then you'd have an array of these question-answer pairs > representing your entire list (which could be encapsulated into a > container class if you wished). > > You could, to be even more abstract, create base question and answer > classes to represent the most basic type of question or answer, and > then hold individual, **related** instances of these within your > question-answer pair class. Do you see the difference? > > You could even take it a step further and build derivatives of your > base answer class to represent different types (string, multiple > choice with one answer, multiple choice with many answers, etc)...But > I'm sure I'm already getting far ahead of your original design. But > David started it! :) > > HTH, > John W -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
