Class Design – Structuring an Online Web Store

classclass-designclass-diagramdesign-patternsuml

I hope I have asked this in the right forum.

Basically, we're designing an Online Store and I am designing the class structure for ordering a product and want some clarification on what I have so far:

So a customer comes, selects their product, chooses the quantity and selects 'Purchase' (I am using the Facade Pattern – So subsystems execute when this action is performed). My class structure:

   < Order >

       < Product >

          <Customer >

There is no inheritance, more Association < Order > has < Product >, < Customer > has < Order > .

Does this structure look ok? I've noticed that I don't handle the "Quantity" separately, I was just going to add this into the "Product" class, but, do you think it should be a class of it's own?

Hope someone can help.

Best Answer

Your company has products it sells to customers. It does this through line-item records on invoices which associate a product and a quantity to the invoice. A typical schema might look something like this:

enter image description here

Related Solutions

Java – A design decision in composition or aggregation

There's a lot to say here.

Inventory's api looks like a value object (since it has no identity, on its own, I suppose that it belongs to a Player). If so, it should be immutable, returning a new instance each time you add or remove an Item.
Your Item class looks like a shared identifier, thus it should override equals and hashcode and (strictly speaking, in DDD term) it should not hold any reference to the icon since it's not useful for its own invariants. You should use a domain service that take the Item and provide the proper icon instead (probably wrapping a statically defined Hashtable). However, be pragmatic with this: if you measure actual performance issues with such (formally correct) approach, keep the field there.
The Slot, as it stands, cannot be considered a domain object, because it does not implement equality in a domain relevant way (it ignores the quantity). This is perfecly correct for a private class internally used by the Inventory, but should not be exposed to clients (as in the second Inventory's implementation of the first solution you proposed). This because the clients could compare for equality two Slots from two different players, obtaining unreliable results.
To get rid of most boilerplate code, I would code
- a supporting functor interface like ItemQuantityChanger (below)
- a "functional" immutable collection, say ItemsSet, with a metod of signature ItemsSet set(Item item, ItemQuantityChanger transformation) that iterates over a simple array for the item to change. Such method would always create a new ItemsSet to return, without the Item (if the trasformation returns zero), with a new Item if the item is not found (with the quantity returned by applying the transformation to zero) or simply with the previous item coupled with the result of the trasformation.

However, concretely, I would just use an ImmutableList.Builder, since the functional design described in 4 adds few value in this case. A single if, in a method, is not that huge smell.

public interface ItemQuantityChanger {
   /**
    * Accept the current quantity of an Item and return the new one.
    */
   int applyTo(int currentQuantity);
}

Best Answer

Related Solutions

Java – A design decision in composition or aggregation

Related Topic