+1  A: 

Hey MackDaddy,

If you need specifics, I can't help you much, but in terms of the logic:

From a purely object-oriented design point of view, I think this is best solved by creating a Cart class to keep track of items. It could be basically a wrapper class for a list of an appropriate sort (language-specific, and I don't know much PHP =P).

I don't see a particular reason to make an item keep track of the cart it's in - in most situations, having the cart keep track makes more sense. (In terms of real-world modeling: do items keep track of the cart they might or might not be in? Nah. But carts are basically just containers for items.)

I'm not quite sure what you're asking in your second question -- could you elaborate, please? Sorry I can't be of more help.

David

dorr
Thanks for the advice David. Here is the basic premise. I have a cart class with an array of items. But with those items I also need to store the quantity. Now to store that cart in a database, I also need to store all the items and their quantities. That's where this class extension comes in. The item linking to the cart is just for the relational database, makes my queries easier. Maybe I'll skip the cart-item class and just have this all managed by the cart class... Thanks for the help though!
MackDaddy
+1  A: 

I'm not 100% sure what kind of usage of the private $data variable you might be doing, so my tendency here would be to take a slightly different approach.

Instead of grouping all your data fields inside a single private variable of the object, I would make each field a private variable itself, ie:

class Item
{
    private $db;
    private $AltItem1;
    private $AltItem2;
...
etc.

This would immediately solve your problem with having publicly available data fields as well, as you could simply declare such fields as a public member. Public members don't require a getter and a setter, so you wouldn't have to worry about that... you could just access them through $this->price (internally), or $item->price (externally). Saves you some code. And it would be a quick modification of your populate() function to set all your new properties, as all you'd have to do would be to set $this->$$key instead of $this->data[$key].

Now, with your use of __set() and __get(), it looks like you want to be able to access the private $data member even from outside the object. There's no reason you can't continue that by having each field declared separately private as well. __set() and __get() will operate exactly the same way, you'd just need a minor adjustment, ie:

public function __get($varname)
{
    if ($this->$varname !== null) return $this->varname;
    error_log("Invalid key '$key'");
    return null;
}

As a final bonus, extending the class becomes easier, because you don't have to redeclare all the fields in their entirety if you want to override the $data property. You simply add the new fields of your children as new private members.

So I'm not sure if that makes your life easier, but I think that would be my approach.

zombat
I like that idea, the only issue is the insert and update methods I just added to the original question. They're kind of odd, but they make the quires a hell of a lot easier. Is there any way I could tie in your method of saving variables with my methods of inserting and updating. Granted I could make a huge long query for including each variable but this way my insert and update methods work across the board for all of my classes as long as they have this $data variable. What do you think?
MackDaddy