-1

How to refactor/rewrite an association into inheritance in the following example. UML Minimal Example SellComputers

The UML Diagram describes the currently working state of my program. The real code structure is more complex so please excuse this made-up example.

There is a Market which initially holds some computers types in a list. When a computer is sold a new object SoldComputer is created and added to a second list. The sold computer references to the computer type. The CPU of the first computer sold can be called by:

soldComupter.ReferenceComputerType.CPU

Is it possible to replace the association with inheritance? Removing ReferenceComputerType and inherit SoldComputer from ComputerType. A call would look like this:

soldComupter.CPU

The goal is not to disguise the reference by a decorator pattern but to descant all field and functionality by inheritance.

The problem i struggle with is, that multiple sold computer can reference the same computer type. So i cant typecast an existing computerType into a soldComputer as both list must exist at the same time in the real application.

Christophe
  • 68,716
  • 7
  • 72
  • 138
DelphiPascalDev
  • 11
  • 2
  • What should that be? If a class inherits it's a sub-class. So `SoldCompiuter` becomes a `Market`. That's plain nonsense as I see it. – qwerty_so Nov 08 '18 at 20:34
  • `SoldComputer` should inherit from `ComputerType`, so it should become a `ComputerType` not a `Market`. Yes `SoldComputer` should become a sub-class of `ComputerType`. – DelphiPascalDev Nov 09 '18 at 09:09
  • I guess its confusing that `SoldComputer` should be a `ComputerType` in this example. Ive got a better example now. Is it okay to rewrite the explanation of the question if the underlying question is still the same? – DelphiPascalDev Nov 09 '18 at 09:14
  • 1
    Yes, you can (and should) edit your question in order to clarify it. However, a computer IS NOT a computer type. It HAS A computer type. – qwerty_so Nov 09 '18 at 10:20
  • Why would you want to "typecast an existing computerType into a soldComputer"? – Gerd Wagner Nov 12 '18 at 11:13

2 Answers2

0

Is it possible to replace the association with inheritance?

No, it's not possible.

As pointed out by @ThomasKilian, "a computer IS NOT a computer type", or put more generally, a product IS NOT a product type.

Your model seems reasonable.

It's very common in business apps to have both a class for product types and another one for individual products, such that these two classes are associated for representing the information which type a product has.

Why would you like to use an inheritance/subclass relationship instead?

Gerd Wagner
  • 5,481
  • 1
  • 22
  • 41
  • Can you elaborate why it is not possible ? Because according to the UML specs, it would be perfectly valid to replace the navigation association with a generalisation. But maybe did you just mean that it shouldn't be done ? – Christophe Nov 11 '18 at 14:41
  • @Christophe: Where did you read that it would be valid to replace the association with a generalisation? These two types of relationships between classes have completely different semantics. – Gerd Wagner Nov 11 '18 at 20:29
  • It's not at all what I said. I said the diagram would be valid it you would replace the relationship: it would just mean something completely different. And that's the reason of OP's question: would the changed meaning be closer to what he/she would like it to express. – Christophe Nov 11 '18 at 21:19
  • @Christophe: It's exactly what you said. Just read your previous comment where you say "according to the UML specs, it would be perfectly valid to replace the navigation association with a generalisation". – Gerd Wagner Nov 11 '18 at 21:44
  • Ok, I was ambiguous. As UML doesn't define replacement rules, I thought it would be clear enough that I was speaking about the diagram before and after the replacement. I hope the reformulation was more precise :-) – Christophe Nov 11 '18 at 21:56
0

If I understand correctly your reasoning, your market sells SoldComputer which are categorized according to a generic ComputerType. Furthermore the ComputerType pre-defines some characteristics of all the computers of that type.

Composition over inheritance

First, a Computer is not a ComputerType. But looking at the properties of these classes, it appears that my argument is only about a naming issue, because your ComputerType could also be named GenericComputer, in which case it would be less shocking.

But your ComputerType is only a small part of the problem. Because sooner or later, you'll realise that a sold computer can also have some StorageType (e.g. HDD, 1To) and maybe also some GraphicType, and many other configurable options. And tomorrow, you may even have new type of components you are not even aware off (e.g. holographic beamer 2D/3D) but that fundamentally do not change the way you describe and categorize the SoldCompter.

This is why you should prefer composition over inheritance: you could have association with other types of components. The big advantage, of your current approach is that if a user decides to extend the RAM of its SoldComputer, he/she can choose just the matching ComputerType and everything is fine.

If you'd go for inheritance, the SoldComputer would have its CPU and its memory: if the user would change their value, it would be inconsistent with the categorisation. And maybe there is no copmuter type corresponding to the new categorisation...

Alternative

Another way to look at the problem is to have a class Computer with all the fields that technically describe the computer (e.g. CPU, memory, disk, etc...):

  • the set of computer types in the market would be populated with Computer but with only some relevant fields filled.
  • the set of sold computers in the market would be populated with Computer having some owner.

The creation of a new Computer to be sold could use the prototype design pattern. But as soon as it is done, there would be no relation anymore between the computer and the prototype.

In this case, the market would no longer be categorised by compter type. The search would always be dynamic (eventually initialised using a choice list of the prototypes.
enter image description here

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • You need to use the multiplicity 0..1 at the `owner` side of your `UserAccount`-`Computer` association. Otherwise your model is inconsistent. And this issue shows that merging individuals with their prototypes into one class is questionable. – Gerd Wagner Nov 11 '18 at 21:42
  • @GerdWagner oops ! You're completely right ! Thanks for pointing it out ! I edited accordingly – Christophe Nov 11 '18 at 21:54