Now there's one more thing I want to add to our diagram and
that's something to represent the idea of multiplicity.
In object diagrams, multiplicity is just a fancy word for
the number of objects represented in a relationship.
This is another one of those things that we're borrowing from UML.
Now multiplicity goes hand and hand with the contains relationships.
If we look back at the world object,
let's ask ourselves some how many questions.
For example,
how many actors are in the world, or how many backgrounds are in a world?
You might say for every world we have what looks like, could be, many actors,
or for every world we might have one background.
And conventionally we use terms like one to many, or many to many, or
even many to one to represent this multiplicity.
So right now if we think about the actors,
we can see that there's two actors on the screen, but there could be more or
there could be worlds where there's no actors at all.
To be honest, we don't really know.
So we could do two things here, since we already have the app built, we could
play around with it some more and find out what are all the different cases for
the number of actors in a world.
Or for what would be the case if we're designing this from scratch and
we didn't have the app already, we could just make a decision and go with it.
For instance, we could say for any given world there may be one to many actors.
We don't know how many, there could be a lot,
there could be a little, doesn't really matter.
We could limit it.
We could say for any one world there's only ever going to be two actors.
But I have a little bit of an advantage because I already know
that there could be one to many actors in a world.
And if we go back to our diagram,
we can add the multiplicity to this contains relationship for actors.
And if we read the multiplicity from left to right, it follows the same order
as our arrows, so for every one world we have, we can have many actors.
Now let's look at another example, this one'll be for
the contains relationship for the background.
>From what we saw there's only one background for the world, so
that means this relationship is 1-to-1.
For every one world object there's one background.
The use of the 1-to-M and the 1-to-1,
this is another thing that we're taking from UML.
So again, this is kind of a blend of both a formal and a informal process.
There's something else that I want to point out and
that is that the relationships themselves and even the multiplicity
can go in different directions, and these arrows could be bidirectional.
For example, right now the world contains 1-to-M actors, but
you may want an arrow going from actor to world that says for
every one actor, it could live in many different worlds.
If it were the case that in the game an actor might show up in
multiple different worlds.
It's really up to you.
You could build these diagrams however you want, but
these are just some really popular conventions.
And if you stick close to these conventions, then it makes it easier for
you to share your diagrams with others.
It also makes it easier to take this diagram and actually start writing code.
And that's why there are the formal processes like UML in place because it
makes it easier to go from something like UML to code, or historically has.
There's one other key takeaway that I want you to leave with and
that is that you should use a process for creating object diagrams
that's the least restrictive to you getting your work done.
I mean, you could spend an entire day, or weeks, designing an object diagram,
but if it doesn't get you any closer to a functioning app,
then you might just be wasting your time.
But there's also great benefit of having some kind of structure in mind before
you build it.
As a developer, you'll discover what works best for you.
Some people like to spend five minutes on an object diagram,
others could spend an entire week.
And another thing is, if you're working with a team,
a good object diagram could be a great way for
the whole team to work together to understand a really complex system.
All right, I'm going to go ahead and wrap things up here.
But if you're interested, here's our final diagram for the Alien Adventure,
so take some time to look at it, and
maybe you have a better idea how to organize things.
Anyways, I hope this was helpful, and I encourage you to reach out to us, or
to your peers if you still have questions.