Thanks, John. It's probably also a matter of how you name the classes. It needs to be a clear name that describes what it 'is'. Hence, the depot name. Anyway, indeed I have finished the concept of the app. Sjef
""John Wells"" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > On 6/30/06, Sjef <[EMAIL PROTECTED]> wrote: >> 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. >> > > Hi Sjef, > > It sounds as if you've got the idea, even if I didn't explain myself > well. My point was to *not* create a Question class that maintained > an array of questions, which was only _implicitly_ related to a > similarly-structured but disparate Answers class. An array of > questions sitting beside an array of answers is, in my opinion, not a > proper abstraction of the objects you're dealing with. > > Perhaps it is out of experience that I'm harping on this point, > because I've been burned by a similar design before. One of my first > OO projects was a weblog, and I had built a Post class, and then for > posts with galleries, a separate Gallery class that contained *only* > image information for it's parent Post. > > On it's own, this wasn't all bad, but the big mistake I made was how I > handled multiple posts and multiple galleries (like for building out > the homepage where I showed 5 recent posts and a thumbnail from each, > if they were galleries). Within each Post and Gallery class, I turned > the properties into _arrays_. So what originally was a string for the > post's title, now became an array of strings for many posts. Likewise > for the Gallery class. Arrays of thumbnails became arrays of arrays > of thumbnails. > > I'm sure The List will shudder at this design, but hey, I've learned > my lesson. Be-lieve-me. Anyway, the point is, your initial approach > was the same (if I read it correctly). You suggested an array of > questions, and an array of answers, which would only be implicitly > related. Your design started with the concept of many questions, and > many answers, but my argument is that, abstractly, you should begin > with one question, and one answer. Then think in terms of a > question-answer pair that *belong to each other*. And then think of > many question-answer pairs. > > Anyway, I'm sure that by the time you've finished reading this > hair-splitting rambling, you've already finished your app and moved on > to something else entirely. :) > > -John W -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
