While reading Craig Larman's Book (Applying UML and Patterns;...) I noticed he added instances of Die class as attributes in the DiceGame class.
.
Is it possible? and there are many related Programming Questions where they negate to do so.
While reading Craig Larman's Book (Applying UML and Patterns;...) I noticed he added instances of Die class as attributes in the DiceGame class.
.
Is it possible? and there are many related Programming Questions where they negate to do so.
These are not instances of Die
but simply two properties of type Die
. The picture is not a very good use of UML (shame on Larman). The association between DiceGame
and Die
use a 2 multiplicity. And most likely he means die1
and die2
with that. But that would be guessing. A better notation would be
with appropriate association-end names.
Short answer: yes... and it happens very often.
In OO there's a neat little trick to figure out if a class should contain a property of some other type of class."Is-A" and "Has-A".
In this case you have a DiceGame class. You ask yourself, "Is-A" DiceGame a Die, or does DiceGame "Has-A" Die. If the answer is the former, then you use inheritance, otherwise you have it set as a property(ies) as in the example you posted.
If you had another class called "GamblingRoom", having a DiceGame a property of that "GamblingRoom" class "could" be a viable solution....depending on what you need to do of course.
Here's a better explanation of it in a similar question to what you have.. but probably better explained than what I did here ;)
I would change the question to, "Can references to any class be treated as attributes in another class?" The answer is technically "yes", but you shouldn't model it that way in UML. You should model simple values as attributes (inside the class' rectangle), but model non-simple references as associations. Simple values are identified only by their values (e.g., the number 5), whereas non-simple references point to things with identity. In your case, each Die
should have an identity other than its current face value. Therefore, you should not model attributes of type Die
, you should model a property at the end of an association.
In the diagram you posted, there are three (!!) properties of type Die
. One is called die1
, one is called die2
, and another is unnamed with a multiplicity of 2
. In a programming language, that would give you four places to store references to your dice, which is obviously incorrect.
The way I would model it is as follows:
When you generate code (or transcribe manually), the dice
property becomes a member variable within DiceGame
. That member variable is usually typed by a collection in your programming language, but it could also be modeled as an array. That collection or array allows you to access both of the dice.
Note that the association is unidirectional. That is because there is probably no need for the Die
to access the Dice Game
. (However, if you needed each Die
to be an active object running in its own thread, you may need the association to be bidirectional so each Die
can send a signal when it's done rolling or something.)
Yes it is possible. OOP provides a container relationship, which means has a relation in which one class can contain instances of another class.
For example, there can be a chair class and a table class and a room class. Now Room can have chairs and tables so room class will have instance of chairs and tables.
It's not only possible, it's the standard case. In fact, many programming languages make no big difference between classes and elementary data types like int
.