I have an order object which contains an array of product objects. I pass a reference of the order to each product object. I was surprised, when outputting the properties of the order to have RECURSION plastered over my page. Apparently this is normal. But it got me wondering whether the approach I’ve taken is the best one, or if there is something better/more elegant. Any comments? Is there a better way to access the order object from within the product object?
It kind of works, but it’s probably not best, exactly for that reason.
It’s not a bad idea, but having a two-direction relationship like that makes life tricky.
By “order”, are you talking like a purchase order, or are you talking just about the order of the products. I’m assuming the first.
What I would do is make it so products don’t contain the order. Is there a reason the products need to know the order? You could make the order object a singleton or a normal global and eliminate the problem.
By “order”, are you talking like a purchase order, or are you talking just about the order of the products. I’m assuming the first.
Sorry, Yes I meant a purchase order, containing products, or rather orderedProducts.
What I would do is make it so products don’t contain the order. Is there a reason the products need to know the order? You could make the order object a singleton or a normal global and eliminate the problem.
There are properties of the order that I would like the product to have access to. Sure I could just pass the properties individually, but would like a bit more flexibility. I’m not convinced a singleton is the right approach in this situation.
Also, this is an issue that’s cropped up before with other object orientated hierarchical structures, and wanted to get myself on the right track. When you say ‘It kind of works’ is there any downside to this approach, so long as I’m not getting myself caught in a loop?
The downside is pretty much just the problem you ran into. The other, usually bigger, problem (which sounds like it’s less likely to crop up in this particular case) is if you change something, making sure all references get properly changed.
Why don’t you think a singleton approach would work in this case? If there should always only be one instance of an order, a singleton would be perfect. I guess you could have multiple simultaneous orders, but that sounds like it’d get quite complex on the end-user side.
The other approach you could use is to split the properties of the order from the array of products it contains. Then, you could pass in just that object and avoid the redundancy.
So, say all the properties of Order get split into OrderProperties. Order contains an instance of OrderProperties and the array of Products. Products is then passed a reference to OrderProperties.
Just some suggestions. 
Could you explain a little more about the scenarios in which your products need to have access to the Order?
Well, there can be more than 1 order. Even if I’m just in a loop replacing the singleton order object each time, the fact that I’m continually replacing a singleton makes it, well, not very single. That’s just my feelings and I have no experience of the practical application of this. (: Like the idea of an order properties object, though.
Could you explain a little more about the scenarios in which your products need to have access to the Order?
I’m mostly thinking way ahead on this, and trying to sidestep problems before I come to them, and actual examples are limited. But say an ordered_product has a tax rate that’s dependant on where the order is getting shipped, or some other property of the order.
If it turned out that I just couldn’t code this way, I’m sure it would be quite easy to code it in another way, and they way might well be ‘better’. But this was the first and most natural approach for me.
Ah, that makes sense as to why you’d need multiple orders. =p
I think in that case, the order properties object would likely be your best approach.
The tax rate should apply to the entire order, though, shouldn’t it? And you will be able to get that rate from the order object itself.
I only bring this up because I’ve run into similar situations in the past, and it usually leads to some very slow code - I’ve usually been able to get around it by just passing both objects to whatever method/view/object needs both things, and that has been a much faster and cleaner way to handle things for me.
Actually, with online orders it can differ (I’ve had Amazon charge me a couple different tax rates on a single order before, because it depends on both the destination and origin in some cases).
In a complicated situation involving multiple sellers, you have to put another tier into place - so each group of products for a seller belongs to it’s own separate order, and an OrderCollection tier above that contains all the separate orders. It’s seamless to the customer (they just see everything they purchased as a single order), but as far as objects and database design it’s treated as separate orders belonging to the master OrderCollection.
That way each seller can be sent it’s own packing list, payment for each seller doesn’t get confusing, and each order can have it’s own tax and shipping rates.
A product though should never need to know about what tax rate was charged for it - that’s for the Order object to know.
Yeah, exactly. That’s why I said that it makes sense to have multiple orders.
Though, it doesn’t really explain why a product needs to know about the order it’s in. =p