I’ve built a matchmaking system where two of the classes look like this:
I know that it actually looks like an inheritance, but in the code it doesn’t extend to the PlayerInMatchmaking and the program is completed and already tested (so I prefer to not change anything). Can I write it as inheritance? If not, then what can I write it? In the picture, I wrote it as aggregation, but aggregation can stand without the related class, while it actually can’t. But if I write it as composition, they are actually not a parent-child relation. Is this kind of design wrong? Any suggestion? Thank you
1
Inheritance is not a goal in life, and there is no reason to introduce it if there is no need. In fact, it is quite the contrary: the usual recommendation is to prefer (object) composition over inheritance.
As you used aggregation (more precisely a “shared aggregation”), be aware that modern UML does not define any semantic for aggregation. The white diamond does therefore not add any meaning to a simple association. So better get rid of it.
If you want to say that the “Parent” requires the “Child” to exist, i.e. that PlayerCandidate requires PlayerinMatchmaking to exist, you should use multiplicity of 1 on the side of PlayerinMatchmaking, meaning that each PlayerCandidate instance must be linked to exactly 1 PayerinMatchmaking instance. (if it’s the contrary, just put the 1 on the opposite side; that’s the ambiguity with Parent/child terminology). (Note: In the following diagram I also showed the property player with a role on the association end, both notations are equivalent)
If you’d like to say that one of the object owns the other, i.e. that the owned object shall be destroyed if the owner is destroyed, you could use UML composition (more precisely, “composite aggregation”). But if you want that the child requires the parent, then you’d need to add a multiplicity of 1 next to the black diamond.
Class diagrams depict the structure of your application, not the rules governing its operation. Some rules can be expressed in the structure of your program, but many cannot. I don’t see anything wrong with your diagram. It clearly depicts that a PlayerCandidate holds a reference to a PlayerInMatchmaking.
Class diagrams are not the place to describe many of the constraints your application needs to adhere to. Other forms of documentation are better equiped to handle this. Requirements documents and unit tests (which should be written based on the requirements) are the first things that come to mind.