Shopping Cart & Product Classes, etc

[nodirtyrockstar]

I'm writing some classes right now for a website with a shopping cart. There are all kinds of classes, Blog, Cart, Product, Database, etc. I am trying to make a design choice about where to store the requested quantity for a particular product. I feel like it should NOT go into the Product class, because the requested quantity does not semantically relate to any of the standard product detail. I was considering maybe setting the quantity property of the product instance, to the requested quantity, once it is put into the cart. For some reason my instinct says no, that it should be abstracted out, perhaps into the Cart class. If that is the case, how do you couple the requested quantity with the requested object? As array key/value pair? Is there another class it could go into? Does anyone have practical experience to shed some light on this?

[nodirtyrockstar]

Requested quantity can't be the key in an array, because it isn't necessarily unique.

Edited December 5, 2013 by nodirtyrockstar

[nodirtyrockstar]

Alright, thanks for reading. I am going with putting it into the Input class.

Edited December 5, 2013 by nodirtyrockstar

[ignace]

When you have something like this, a bunch of classes and some functionality, and you don't know where to put it, you need to analyse your model and try to find missing components.

 

In your case, you are missing Order. Your Customer Orders a Product by placing it into his Cart.

 

$order = new Order($someProduct, 12);
$cart->add($order);

[nodirtyrockstar]

That is what I am doing with the Input class.

[ignace]

Every class should have a single responsibility, forcing the responsibilities of Order onto Input means it is doing work it shouldn't have to. It also makes it harder for future developers working on your project to continue development due to classes having responsibilities that they are not aware of.

 

Which is why it's best to make your model as explicit as possible. And Order is a better name (since the customer orders a product by placing it into his basket) then Input. Just like you would have a Product class instead of naming it Input as well.

 

Input is better suited for all incoming request data. So that you can do:

 

$input->get('product_id');
$input->post('product_id');
// etc

Not to represent an Order or Product.

[nodirtyrockstar]

I think you are making a lot of assumptions about what classes I have and what they are doing. My input class only does one thing. It handles input. The way I handle the user's order is not something I really went into on here, but suffice it to say, it is separate from the Input class.

Edited December 9, 2013 by nodirtyrockstar