OOP Help

[dardub]

I'm trying to get used to use objects in php, but my mind still thinks in arrays and relational databases. I'm looking for guidance in how this should be done. I'm doing this using magento, but I'm just having trouble with the basic php implementation.

 

I have a products page that creates a bundle. Lets say for instance I'm creating a custom computer.

 

The user can pick out a motherboard, memory, hd, etc. They can only pick one of each of these.

The user can pick accessories which there can pick as many as they want.

 

The items the user selected is then displayed on the bottom of the page for each item.  Once they are done they can check out all the items.

 

When the user selects a product I want to store the item id and qty into a session cookie.  What I'm doing now is creating an object for each product category assigning the id and qty to the object and then saving to the session.  If a user selects another product in the same category, it overwrites the session storing that object (which is what I want). 

The problem I see for the accessories, is I would need to define a product object for each individual accessory. This way of doing it doesn't make sense to me. 

 

I feel like I should be setting all this information into a products array and then saving the session.  Am I just trying to force OOP when using an array would suffice?

[the182guy]

Am I just trying to force OOP when using an array would suffice?

 

Exactly right, use an array for that. Storing objects in the session means the server has to work harder than if it was an array.

[dardub]

Yeah, as I thought about it more, I couldn't justify a reason to use it as an object.  I'm sure I'll get my chance to create some new classes some day. 

[sunwukung]

Not so fast!

It really depends on the usage/application design.

 

You could make a single "cart" object, and each item the user picks then becomes a property of the cart. That might take the form of a discrete property for each item, or alternatively part of an associative array which can be used as a reference point from which you can pull up product data if the user wishes to review their purchases later. You can then persist the object in medium X (a database would allow you to keep the cart data on hand for the next time the user logs in).

 

On the other hand, it may be overkill if that's ALL the cart does, since that will reduce the object to little more than an expensive associative array. You may, however, think of additional functionality to append to the cart which can then be brought to bear on the cart contents, like sorting, adding, removing, changing quantities etc...

 

Try to think of the "cart" as representing an object in the real world - what would it do? This is fundamental to the concept of the Domain Model, a conceptual model of a given business domain. Since all data can be represented as arrays, why use objects at all?

 

I'd recommend reading up on Domain Modelling, it will help bridge the gap from OOP theory to practice:

http://www.infoq.com/minibooks/domain-driven-design-quickly

[the182guy]

Not so fast!

It really depends on the usage/application design.

 

You could make a single "cart" object, and each item the user picks then becomes a property of the cart. That might take the form of a discrete property for each item, or alternatively part of an associative array which can be used as a reference point from which you can pull up product data if the user wishes to review their purchases later. You can then persist the object in medium X (a database would allow you to keep the cart data on hand for the next time the user logs in).

 

On the other hand, it may be overkill if that's ALL the cart does, since that will reduce the object to little more than an expensive associative array. You may, however, think of additional functionality to append to the cart which can then be brought to bear on the cart contents, like sorting, adding, removing, changing quantities etc...

 

Try to think of the "cart" as representing an object in the real world - what would it do? This is fundamental to the concept of the Domain Model, a conceptual model of a given business domain. Since all data can be represented as arrays, why use objects at all?

 

I'd recommend reading up on Domain Modelling, it will help bridge the gap from OOP theory to practice:

http://www.infoq.com/minibooks/domain-driven-design-quickly

 

Might just work if you only plan on getting 5 hits per day. If you want to cater for more than that though you'll need to do what all the other open source shopping cart software do, which is to use an array to store cart items in the session. You can or should still have a cart object to encapsulate functions like add/delete products, update quantity. The cart array in session is simply a datastore to persist the contents of the cart across requests.

 

If you're looking at developing E-Commerce style software then the best thing you can do is to look at how others have done it.

[KevinM1]

Here's how I'd do it:

 

Create a Computer class.  The required components would be the key data members of the object.  The accessories would be stored as an associative array within the object.  So, something like the following (which is intended only as a rough sketch):

 

class Computer
{
   private $motherboard;
   private $cpu;
   private $memory;
   private $hdd;
   private $accessories = array();

   public function addAccessory($name, $price)
   {
      if (array_key_exists($name, $this->accessories))
      {
         ++$this->accessories[$name]['quantity'];
      }
      else
      {
         $this->accessories[$name] = array('price' => $price, 'quantity' => 1);
      }
   }
}

[ignace]

The user can pick out a motherboard, memory, hd, etc. They can only pick one of each of these.

 

You can't be serious. You will lose a lot of clients if you pursue this. Server administrators for example buy motherboards which have 2 sockets which means they also will buy 2 CPU's. Not to mention gamers which now standard buy 2 GPU's for SLI/CrossFire.

[dardub]

@ignace,

 

lol, no I'm not serious. I was just using as an example as I mentioned.  You're trying too hard to be a nerd. 

[JonnoTheDev]

http://www.phpfreaks.com/forums/index.php/topic,294324.msg1393195.html

[dardub]

Thanks for the info Nightslayer.  The code made things a little more clear. I already changed everything to a 2d array yesterday since I just needed to pass the id and qty for each item.

 

One question, I'm not sure the best way to set the id and qty for the motherboard for the code you showed:

 

would i do something like:

 

private $itemId;
private $itemQty;

public function setMobo($id, $qty){
  $this->motherboard->itemId = $id;
  $this->motherboard->itemQty; = $qty;

}

 

Or is there a more general way?

[ignace]

@ignace,

 

lol, no I'm not serious. I was just using as an example as I mentioned.  You're trying too hard to be a nerd. 

 

GEEK, big difference. If you want to insult me at least get your naming right.

[KevinM1]

Thanks for the info Nightslayer.  The code made things a little more clear. I already changed everything to a 2d array yesterday since I just needed to pass the id and qty for each item.

 

One question, I'm not sure the best way to set the id and qty for the motherboard for the code you showed:

 

would i do something like:

 

private $itemId;
private $itemQty;

public function setMobo($id, $qty){
  $this->motherboard->itemId = $id;
  $this->motherboard->itemQty; = $qty;

}

 

Or is there a more general way?

 

You could do it that way, put the info in a 2D array like the accessories, or make small struct-like objects to contain the data.