CODEWITHSUNDEEP
umlclass-diagramredundancy
Gherkin in God mode
Gherkin in God mode

Reputation: 323

Which class structure would be most suitable for the set up?

I am working on a university assignment for a Object Oriented design module. Following linguistic analysis of nouns and verbs, and identification of use cases, the class diagram is now being made.

The relevant parts of the program are as follows:

This leads me to think that any details associated with the order for a product can be listed as attributes for that product object, as opposed to being attributes of an order object that is linked to the product object. If there was multiple orders per product I would definitely make an order list in addition to a product list however there is just 1 per product.

The issue is that having all product attributes (name, weight, shelf life, ID, cost per unit, sales velocity, photo etc) and all order attributes (estimated date to order, amount to order, delivery date, amount owed to supplier, date of last order), as attributes of the product would make the product class cumbersome. Alternatively, separating them into two classes may create redundancy. Furthermore, most of the order 'attributes' are actually results of calculations performed using product attributes, not 'base attributes' (apologies for incorrect terminology).

The options for class diagram are shown below. please forgive me for lack of detail as this is just a mock up to visualise what is in the question above.

Option 1:

Option 1

Option 2:

Option 2

Any help on which (if either) class diagram to select would be really appreciated, and any other info that may come to mind whilst reading the question would also be appreciated.

Upvotes: 1

Views: 67

Answers (1)

Christophe
Christophe

Reputation: 73396

The key to successful OO design is separation of concerns. This means that if you know there are things that are inherent to the product and other things thar are related to an order of that product, you should separate them.

Now, after 20 years in ERP, I can tell you that one order at a time is only a temporary situation. Sooner or later, you'll have to evolve, so better anticipate if it is this obvious. So option 2 is the way to go.

Now you should do a couple of things in your diagram:

  • First, add multiplicity.
  • Use arrows, only if you really want to express unidirectional navigability. In your case I srongly advise against it.
  • Your associations between Product, Order, Supplier and External Company do not match your narrative. You said that each product has an associated supplier and delivery company. So there should be a direct link between those. You also said that a supplier CAN have an external company as parent. So there could be orders without any external parent company.
  • Of course, it is implicit, but an order would also have a company. And even if at a given time it's only one, if you persist this in a database, you shall be able to reliably find the order of any given supplier, even former ones.
  • Do not hesitate to label the associations to add expressivity to your diagram. Because some association may appear redundant, but are not at all if looking at their meaning.

Now last thing: I do not know about your assignment, but I'd advise to focus on the domain classes and let the GUI out. Why ? because once you start with the GUI, you'd certainly have GUI subclasses that are associated with other things than just the product list. As it is, I find it misleading.

Upvotes: 1

Related Questions