Re: OO Application Design

I believe you should have getAdults as a class method in class Person and let it return an object of type PersonList. A PersonList should just contain the handle of the executed statement (in other words a cursor or ResultSet) and wouldn't hold all elements in memory. It could have methods like get_next, has_more_elements, as_array, letting you either access elements sequentially or get all the bunch as an array.

In a more general setting, a PersonList could be an instance of a superclass DBObjectList, ~~knowing~~ aware of what kind of objects it is retrieving (in your case Person's).

Antonio

Comment on Re: OO Application Design

Replies are listed 'Best First'.

Re: Re: OO Application Design
by Nomad (Pilgrim) on Sep 26, 2002 at 07:28 UTC

I've found this the best way to do it, mostly because it allows lots of generalising and lots of use of polymorphism.

I have objects of class Person, Invoice, Business etc and they all basically want the same methods called on them. Using a class method Person->newIterator actually returns an instance of PersonIterator which is subclassed from DBIterator.

PersonInterator, etc, instances are created on the fly and how they behave depends on the arguments passed by newIterator. Because all the Person, Business, etc classes are all subclassed from the same Entity class, the calling program doesn't actually have to know what class it is dealing with.

So calling: $any_Iterator = $any_class->newInterator

returns a an instance of something subclassed from DBIterator. Note DBIterator, itself, is abstract.

Then you can keep calling: $any_Iterator->nextElement;

until it returns undef.

Is this a naughty use of symbolic refs? I don't know. But what I do know is that I find this code easy to maintain easy to extend and easy to tweak.

[reply]
[d/l]
[select]


P is for Practical
	PerlMonks