managing list of objects(collection class?)

[coo_t2]

Hey all. I'm some classes to be part of an auction script.
I am going to have a "Bidder" object represent each bidder.
This object will give me all the details I need about each individual bidder.

But I also need to handle a group of bidders. For instance when someone is
viewing the auction page I want to show the list of bidders that bidded on that item.

So I need a class that manages a group of "Bidder" objects.
Is this what a collection class is for?

What I was thinking about doing was creating a "BidderList" class,
or something similar. The "BidderList" would probably take the auction ID as
a parameter in the constructor and load a bunch of "Bidder" objects, for each
bidder associated with that auction.

But I might allow some other alternative parameters for deciding which bidders to get.
For instance I might wanna get the bidders who've bidded in a particular category.
Or I may want to choose bidders based on some other criteria.
The "BidderList" class should be flexible enough to let that criteria change with
the situation.

I was also thinking of having the "BidderList" class extend a "Collection"(or similar)
class. I can use that as an abstract class or interface to define a standard way of
doing things in case I want a collection of some other types of objects in
the future.

The "BidderList" class should give you the access to all the methods that
you would normally have on a "Bidder" object, must also need to include methods
for managing a list. Features such as iteration, etc..


So I have a few questions.

1. Am I on the right track with my thinking?
2. Is there a pattern or something I could look at to figure out how
to do this the right way?
3. What if there's a lot of bidders on a particular auction.
Isn't it inefficient to create all those objects?
It could make a difference on a high traffic site couldn't it?

tia,
--ed

[Dr Livingston]

PHP OOP is very effiecent so I wouldn't worry too much about the number of objects; although there is I believe a way of killing an object once you've finished with it ? If you do this, then it'll lessen the load I suppose, but generally though, it's not a problem. About the other points, I'd like to think that a collection of bidders would be a good idea, with another collections to assocc their categories ? An iterator would help out here a lot IMO as well; proberly looking at arrays of objects ?

[codezilla]

So I need a class that manages a group of "Bidder" objects. Is this what a collection class is for?

Yes! A collection is just a group of objects. So an array of Bidder objects could be considered a collection. Note that you don't have to have a special collection class (like an ArrayList or HashMap), a simple array may suffice.

1. Am I on the right track with my thinking?

Mostly. However, collection classes are meant to be general-purpose. In other words, I wouldn't recommend having a specific BidderList class. Instead, implement a Data Access Object (DAO) that will populate an array (or even an ArrayList object) with only the desired Bidder objects.

2. Is there a pattern or something I could look at to figure out how to do this the right way?

Collections are pretty basic. Even more basic than design patterns (assuming that's what you were referring to). There's nothing wrong with using plain ol' arrays. If you want to go the OO route, I recommend having an ArrayList and a HashMap class in your library. I modelled my own classes after Java's:

http://java.sun.com/j2se/1.4.1/docs/...ArrayList.html
http://java.sun.com/j2se/1.4.1/docs/...l/HashMap.html

Here's a simple example (using an array):

$dao =& new BidderDao();
$list = $dao->findForAuctionId($_GET['auction_id']);
foreach ($list as $bidder)
{
    echo $bidder->getName();
} 

The ArrayList version doesn't look that much differnt:

$dao =& new BidderDao();
$list =& $dao->findForAuctionId($_GET['auction_id']);
$i =& $list->iterator();
while ($i->hasNext())
{
    $bidder =& $i->next();
    echo $bidder->getName();
} 

Of course, in these example, the bulk of the work is happening in BidderDao class (and the classes it depends upon), so this example may raise more questions than it answers.

3. What if there's a lot of bidders on a particular auction.
Isn't it inefficient to create all those objects?
It could make a difference on a high traffic site couldn't it?

I don't know exactly how much the performance is affected when you use objects in this manner. It's not the fastest in terms of execution speed, but it is still a viable option.

[codezilla]

coo_t2, I just posted a reply to your "keeping queries out of classes " thread which should hopefully explain the DAO part a little more.

[shoebox]

Another question about doing things this way rather than just processing the record set as is.

Say we want to print these in a table format and we have a UNIX timestamp that needs to be formatted as a string time.

In this Bidder class cuold we put in formatting in the get* methods?

For example:

// $this->timestamp is a UNIX timestamp in this case
//  so we need to format it.
function getTimestamp()
{
	 return FormatTime::mmddyy($this->timestamp);
}

then in your setmethod you would make sure that the value is always "db ready"

something like:

function setTimestamp($val)
{
	 if (is_integer($val) {
		  $this->timestamp = $val;
	 } else {
		  $this->timestamp = strtotime($val) 
	 }
}

[codezilla]

Yeah, basically. I'd probably do something like this:

class Bidder
{
    var $date; // a unix timestamp
    
    // . . .

    function getDate($format = 'F j, Y')
    {
        return date($format, $this->date);
    }

    function setDate($val)
    {
        $this->date = (int) $val;
    }
    
    // . . .