This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hopefully this is isn't a beginner level question.
I'm in the early stages of developing a shopping cart application (specific to an individual retail business).
My design includes the following two classes: Product, and ProductGrouping (because the company sells tableware, and the products are grouped into patterns). The ProductGrouping contains a List<Product> (an ArrayList). What I'm finding, however, is that given a particular Product, I want to be able to get a reference to the ProductGrouping (to be able to access information such as the pattern name, manufacturer name etc.). My concern is that giving each Product a reference to its ProductGrouping would lead to tight coupling between the two classes and therefore feels like a bad idea.
I personally don't see a massive problem with putting in the ProductGroupId on the Product, as you say it can speed those reverse lookups somewhat. Others may disagree with this opinion though, I'm hoping they'll weigh in!
Joined: Feb 25, 2007
Thanks for the response, Martijn. I'm inclined to agree with you, but would be interested if anyone thinks it's a crazy thing to do.
If you get a request which says "Show me the information for Product 123" and "the information" would include the product group's description, then that would be a reasonable design. I would rather ask why the product group needs a list of products in that group.
Joined: Feb 25, 2007
Yeah. An example would probably clarify things.
When you display a product, the name "Wedgwood Jasper Conran Blue Butterfly Plate 27cm" is actually made up of information from a number of objects:
Wedgwood is the Manufacturer's name.
Jasper Conran is the Designer's name (won't exist for some patterns)
Blue Butterfly is the ProductGrouping (pattern) name
Plate 27 is obviously the product name.
ProductGrouping has Manufacturer and Designer member variables.
The name of the product itself really isn't enough. For example, in the shopping cart, you want the full name mentioned above.
With regards to the question of why the ProductGrouping has to have a list of products in that group, possibly it doesn't. My initial thought was simply to give each of the Product objects a reference to the ProductGrouping.
But then, logically it just seemed to make sense for the ProductGrouping to have a list of the products within it: It makes it very easy to loop through the products in the view (the most important page on the site will be one that displays all products within a ProductGrouping).
I suppose there's nothing stopping me using a list of products for a given ProductGrouping without making it a member of that ProductGrouping.
Given the concerns above, would you say that approach makes more sense?
btw, I very much appreciate the feedback as I'm a lone developer on this project.
That's what I expected, that there would be a page which displayed all the products in a grouping. You could implement that by going through all the products and only displaying those which were in a specific grouping, but if there were 15,000 products and you wanted to display a grouping with only 15 products, you could decide that was a waste of resources. But it might not be in real life, it might make the response time for the page be 1.2 seconds with the pre-built list of products and 1.7 seconds without it.
The point I'm trying to make, I think, is that your data design has to be driven by the way the data is going to be used. If you wanted a page which showed all products for a designer, then you might want to build that list in advance for each designer too. Or not, again taking response time into consideration. You should really start out with the simplest possible design, then add complications as necessary in response to requirements.