Refactor Reference/Association to Inheritance
up vote
-1
down vote
favorite
How to refactor/rewrite an association into inheritance in the following example. 
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.
delphi design-patterns uml
asked Nov 8 at 15:19
DelphiPascalDev
62
add a comment |
up vote
-1
down vote
favorite
How to refactor/rewrite an association into inheritance in the following example.
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.
delphi design-patterns uml
asked Nov 8 at 15:19
DelphiPascalDev
62
What should that be? If a class inherits it's a sub-class. SoSoldCompiuterbecomes aMarket. That's plain nonsense as I see it.
– Thomas Kilian
Nov 8 at 20:34
SoldComputershould inherit fromComputerType, so it should become aComputerTypenot aMarket. YesSoldComputershould become a sub-class ofComputerType.
– DelphiPascalDev
Nov 9 at 9:09
I guess its confusing thatSoldComputershould be aComputerTypein 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 9 at 9: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.
– Thomas Kilian
Nov 9 at 10:20
Why would you want to "typecast an existing computerType into a soldComputer"?
– Gerd Wagner
Nov 12 at 11:13
add a comment |
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
How to refactor/rewrite an association into inheritance in the following example.
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.
delphi design-patterns uml
asked Nov 8 at 15:19
DelphiPascalDev
62
How to refactor/rewrite an association into inheritance in the following example.
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.
delphi design-patterns uml
delphi design-patterns uml
asked Nov 8 at 15:19
DelphiPascalDev
62
asked Nov 8 at 15:19
DelphiPascalDev
62
edited Nov 9 at 10:49
asked Nov 8 at 15:19
DelphiPascalDev
62
asked Nov 8 at 15:19
DelphiPascalDev
62
asked Nov 8 at 15:19
DelphiPascalDev
62
62
What should that be? If a class inherits it's a sub-class. SoSoldCompiuterbecomes aMarket. That's plain nonsense as I see it.
– Thomas Kilian
Nov 8 at 20:34
SoldComputershould inherit fromComputerType, so it should become aComputerTypenot aMarket. YesSoldComputershould become a sub-class ofComputerType.
– DelphiPascalDev
Nov 9 at 9:09
I guess its confusing thatSoldComputershould be aComputerTypein 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 9 at 9: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.
– Thomas Kilian
Nov 9 at 10:20
Why would you want to "typecast an existing computerType into a soldComputer"?
– Gerd Wagner
Nov 12 at 11:13
add a comment |
What should that be? If a class inherits it's a sub-class. SoSoldCompiuterbecomes aMarket. That's plain nonsense as I see it.
– Thomas Kilian
Nov 8 at 20:34
SoldComputershould inherit fromComputerType, so it should become aComputerTypenot aMarket. YesSoldComputershould become a sub-class ofComputerType.
– DelphiPascalDev
Nov 9 at 9:09
I guess its confusing thatSoldComputershould be aComputerTypein 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 9 at 9: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.
– Thomas Kilian
Nov 9 at 10:20
Why would you want to "typecast an existing computerType into a soldComputer"?
– Gerd Wagner
Nov 12 at 11:13
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.– Thomas Kilian
Nov 8 at 20:34
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.– Thomas Kilian
Nov 8 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 9 at 9:09
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 9 at 9: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 9 at 9:14
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 9 at 9:14
1
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.
– Thomas Kilian
Nov 9 at 10:20
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.
– Thomas Kilian
Nov 9 at 10:20
Why would you want to "typecast an existing computerType into a soldComputer"?
– Gerd Wagner
Nov 12 at 11:13
Why would you want to "typecast an existing computerType into a soldComputer"?
– Gerd Wagner
Nov 12 at 11:13
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
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
Computerbut with only some relevant fields filled. - the set of sold computers in the market would be populated with
Computerhaving 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.
answered Nov 11 at 14:38
Christophe
38.4k43473
You need to use the multiplicity 0..1 at theownerside of yourUserAccount-Computerassociation. Otherwise your model is inconsistent. And this issue shows that merging individuals with their prototypes into one class is questionable.
– Gerd Wagner
Nov 11 at 21:42
@GerdWagner oops ! You're completely right ! Thanks for pointing it out ! I edited accordingly
– Christophe
Nov 11 at 21:54
add a comment |
up vote
0
down vote
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?
answered Nov 9 at 9:44
Gerd Wagner
2,99911328
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 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 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 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 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 at 21:56
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
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
Computerbut with only some relevant fields filled. - the set of sold computers in the market would be populated with
Computerhaving 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.
answered Nov 11 at 14:38
Christophe
38.4k43473
You need to use the multiplicity 0..1 at theownerside of yourUserAccount-Computerassociation. Otherwise your model is inconsistent. And this issue shows that merging individuals with their prototypes into one class is questionable.
– Gerd Wagner
Nov 11 at 21:42
@GerdWagner oops ! You're completely right ! Thanks for pointing it out ! I edited accordingly
– Christophe
Nov 11 at 21:54
add a comment |
up vote
0
down vote
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
Computerbut with only some relevant fields filled. - the set of sold computers in the market would be populated with
Computerhaving 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.
answered Nov 11 at 14:38
Christophe
38.4k43473
You need to use the multiplicity 0..1 at theownerside of yourUserAccount-Computerassociation. Otherwise your model is inconsistent. And this issue shows that merging individuals with their prototypes into one class is questionable.
– Gerd Wagner
Nov 11 at 21:42
@GerdWagner oops ! You're completely right ! Thanks for pointing it out ! I edited accordingly
– Christophe
Nov 11 at 21:54
add a comment |
up vote
0
down vote
up vote
0
down vote
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
Computerbut with only some relevant fields filled. - the set of sold computers in the market would be populated with
Computerhaving 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.
answered Nov 11 at 14:38
Christophe
38.4k43473
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
Computerbut with only some relevant fields filled. - the set of sold computers in the market would be populated with
Computerhaving 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.
answered Nov 11 at 14:38
Christophe
38.4k43473
edited Nov 11 at 21:53
answered Nov 11 at 14:38
Christophe
38.4k43473
answered Nov 11 at 14:38
Christophe
38.4k43473
answered Nov 11 at 14:38
Christophe
38.4k43473
38.4k43473
You need to use the multiplicity 0..1 at theownerside of yourUserAccount-Computerassociation. Otherwise your model is inconsistent. And this issue shows that merging individuals with their prototypes into one class is questionable.
– Gerd Wagner
Nov 11 at 21:42
@GerdWagner oops ! You're completely right ! Thanks for pointing it out ! I edited accordingly
– Christophe
Nov 11 at 21:54
add a comment |
You need to use the multiplicity 0..1 at theownerside of yourUserAccount-Computerassociation. Otherwise your model is inconsistent. And this issue shows that merging individuals with their prototypes into one class is questionable.
– Gerd Wagner
Nov 11 at 21:42
@GerdWagner oops ! You're completely right ! Thanks for pointing it out ! I edited accordingly
– Christophe
Nov 11 at 21:54
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 at 21:42
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 at 21:42
@GerdWagner oops ! You're completely right ! Thanks for pointing it out ! I edited accordingly
– Christophe
Nov 11 at 21:54
@GerdWagner oops ! You're completely right ! Thanks for pointing it out ! I edited accordingly
– Christophe
Nov 11 at 21:54
add a comment |
up vote
0
down vote
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?
answered Nov 9 at 9:44
Gerd Wagner
2,99911328
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 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 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 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 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 at 21:56
add a comment |
up vote
0
down vote
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?
answered Nov 9 at 9:44
Gerd Wagner
2,99911328
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 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 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 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 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 at 21:56
add a comment |
up vote
0
down vote
up vote
0
down vote
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?
answered Nov 9 at 9:44
Gerd Wagner
2,99911328
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?
answered Nov 9 at 9:44
Gerd Wagner
2,99911328
edited Nov 12 at 11:13
answered Nov 9 at 9:44
Gerd Wagner
2,99911328
answered Nov 9 at 9:44
Gerd Wagner
2,99911328
answered Nov 9 at 9:44
Gerd Wagner
2,99911328
2,99911328
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 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 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 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 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 at 21:56
add a comment |
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 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 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 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 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 at 21:56
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 at 14: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 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 at 20:29
@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 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 at 21:19
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 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 at 21:44
@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 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 at 21:56
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 at 21:56
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53210754%2frefactor-reference-association-to-inheritance%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What should that be? If a class inherits it's a sub-class. So
SoldCompiuterbecomes aMarket. That's plain nonsense as I see it.– Thomas Kilian
Nov 8 at 20:34
SoldComputershould inherit fromComputerType, so it should become aComputerTypenot aMarket. YesSoldComputershould become a sub-class ofComputerType.– DelphiPascalDev
Nov 9 at 9:09
I guess its confusing that
SoldComputershould be aComputerTypein 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 9 at 9: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.
– Thomas Kilian
Nov 9 at 10:20
Why would you want to "typecast an existing computerType into a soldComputer"?
– Gerd Wagner
Nov 12 at 11:13