So we finally reached module 11, where
we'll actually start designing and implementing
our own classes. Here are the learning objectives for
module 11. In all the weeks up until this point,
we've been focused on using classes that are provided by C#, or by XNA, or by
me in the course materials. And so that's an important first step,
with dealing in Object Oriented systems,
learning how to use classes and objects that are available
to you because of work other people have
done. Now it's time for us to start actually
working on the design and implementation of our own
classes. And so, that's what we'll do within this
module, we'll do a class for a Console Application, and then we'll do a
class for an XNA game, as well. You should recall from way back in module 4 that objects have three different
things. They have state, they have behavior and
they have identity. And so, the state of an object is all
about the characteristics of that object. So you should go do an in-lecture quiz about, demonstrating that you remember how
we actually store the state of an object. And now, you should do another in-lecture
quiz that demonstrates that you remember how we actually provide consumers of the
class that the object is an instance of. How we provide consumers access to the
state of that object. Okay. So the next thing that we worry about, or
need to be concerned with, is the behavior of
the object. So what can that object do, or interestingly enough, what
can we tell the objects to do to itself? So, another in-lecture quiz to demonstrate
that you remember how we do that part in C#. And finally, we have identity. Well, objects have identity.
We do too, but objects have identity. So, this lets us distinguish one object from another. And so, the third thing we need for
objects is of course identity and we will actually get identity when we call the
constructor, to create a new object. [BLANK_AUDIO]. So let's build a Die Class.
A die is a, thing that we roll. It has a certain number of faces. And so, we're, we'll come up with a design
for a die that corresponds to a die in the real world.
And so first, we'll start with state. What are the kinds of things that we need
to store for state in the die class? Well, we need to remember how many sides a
die has. So a standard die has six sides, but if
you happen to be a dungeons and dragons player maybe you
think a standard die has 20 sides. And so, we need to store within the die
how many sides it has, and will tell it how
many sides it has when we actually construct the die object just as the die factory determines
how many faces are on the die when they actually build the die and you know, a physical
die. So, we'll have to keep track of that for
state how many sides there are. And we'll also need to keep track of which
side is on top, because typically, people will use
one or more dice for a game, and so you'll roll the dice and
you'll look at the number that's on top and you do
something with it. Whether you pay money or move forward on
the board, or you know, the Orc has slashed you
fatally, or whatever. But we use the number on the top of the
die for some particular reason. So we're going to need to store that as
well. And so, as you know from the earlier in lecture quizzes, and your work with C# so
far. We're going to store the state of the
object in fields. And then we're going to provide consumers
access to the state of the object through
properties. Next thing is behavior, and we're only
going to do one thing for behavior. We are going to tell the die to roll
itself. So that's how we'll use dice. We'll tell a die to roll itself, and then
we'll look at the top side and say, oh okay, now I know
it's facing up and take the appropriate action based
on the game we're playing. And finally, we of course gives dies, each
die object, identity, and that will happen when we call the constructor
to actually build the die object. So sort of pictorially, this is what we've
come up with. So remember the information hiding thing. We're going to hide the fields NumSides
and TopSide in the internals of the object. So a consumer of the object can't see
those things, and that way if we decide we want to change how we represent those
things later we can, without affecting any consumers of
the object. So that's the information hiding part. Encapsulation remember? Is putting the data, that stuff in the
inner hold of the donut, I must be hungry right
now. The inner hole of the donut, encapsuling
the data along with the behavior. And the behavior in our case is rolling
the die as a method. In that capsule, the membrane of the
capsule, also makes it so that consumers access the data
through those two properties. So they get of the behavior through the
method, and that they gather the data [SOUND] through the properties. That previous picture was not in any
standard pictorial form. This is in fact, the UML diagram for the
class that we're going to build. So as you can see, we have the fields, that will use to store the state
internally. And then we have the properties, that a
consumer of the class will use to access that
state. And then finally we have the method, so they can
also get at the behaviors. We typically do not include the
constructor, one or more constructors in the UML
diagram. So I haven't done that here, but
understand that of course we'll have at least one constructor so that we can in
fact create new instances of the class. So now let's actually start doing this.
So I'm going to start up Visual Studio. Now, we're going to start a new project. This one is going to be a Console
Application. So, I'll say it's a New Project, a Console
Application, and I'll call it [SOUND]. I'll call it die.
Okay? [INAUDIBLE], I guess I can't.
I'll, I'll call it the die example [SOUND]. I can't bring myself to just call it die.
So I'm going to create this new project. I'm going to zoom in, immediately, and I'm
going to save. [SOUND]. So, I will go Save and then we'll jump
back into the video. Okay, so I have saved it and I also snuck
in and added comments. Almost all the comments that I should have
added [SOUND]. There we go. So, we want to actually create a new
class, which means we need a new file. And so, over here, where it says, die example, the, the boldfaced, this is the
project. I right click that, and I say, Add a new
item at the top or pick of the class at the bottom and so common
for us to add classes that we get our very own option in the drop-down for that. I am going to add a class and I'm going to
rename it, Die with a capital D [SOUND]. And I'm going to zoom in [SOUND]. And so [SOUND] this is a die. Now, I will F6 just to demonstrate that
everything still works. Now, I'm going to the first thing that I'm going to do, is add the fields for the
class. So I'm going to add a region [SOUND]. And remember that region using regions is
just for within the IDE. It has nothing to do with what gets executed when we actually compile and run
our code. And so, I knew that I needed two things
for fields. I needed the number of sides for the die,
and I need which side is on top. So both of those really ought to be
integers. We, we really can't have dice with six and a half sides. Soon as you cut it there's an extra side,
that's why diamond cutters are so rich or
something, I don't know. Okay, so let's, they're both ints. So I'll call the number of sides numSides,
just as we saw in the UML. And I'll also call the top side that we're
saving, topSide, just as you'd expect in the, from
the UML. So, at this point, I can compile again. But, I have added both the numSides field,
and the topSide field to this new class that I
created. You should now go do an in-lecture quiz,
that asks about controlling access to these fields, and then come back
and we'll talk about it. So, a new thing that we haven't talked
about yet because we haven't been developing our
own classes, is that there's another word that can go
here before we put the data type, and the
variable name. Up to this point, right? This is just exactly declaring a variable,
because it is a variable within the class. But we can also set what's called an
Access Modifier. So we can, if we choose to do so, we can
do something like this. [SOUND]. Say, public. We could make our numSides field public,
which means that any consumer of this class can directly manipulate our
numSides field. And that is generally considered very bad
programming practice. We don't care about it for constants, it's
okay to make constants public. We don't have any right here. But it's okay to make constants public, because nobody can mess
them up, essentially. But making a field public, really bad
idea. If we do that we have basically taken odd
picture of the class.
And we've done this. We've said, okay.
You can directly manipulate NumSides. So I'm going to dig a hole. I'll break that information hiding thing,
so that you can tunnel your way into the core of my class, and mess
around with the internals. That is such a horrible idea. It is allowed by the language, but it's a
terrible idea. You should never do it.
Let me [UNKNOWN] out lest you think that, that's the best
thing ever. So really what we want, is we want all of
our fields to be private. We don't want anyone external to the class
to be able to see those fields in any way. And because we want them all to be private
in general and because it is such good
programming practice, they're actually private by default. So really, for changing the Access
Modifier for a field, the only way for you to mess up is if you deliberately
decide to be a bad programmer. Morally bad, not just, you know, bad code quality, just a bad person, I'll make this
public. So don't do it. Right. It's, it just, it breaks our information
hiding and there's no need to do it. Because, if consumers of the class need access to
the state, which is what are fields are for,
then we provide them access to that state
through our properties, which means we should actually
implement some properties. So I'm going to create another region [NOISE]. And here's where I'm going to implement
our properties. So let's implement the numSides property
first. We need to put an Access Modifier for the
property, and because this is for consumers of the class, we
want to make properties public. In general, we want to make the properties
public, because the consumer of the class needs
access to it. The numSides field is an integer, so we're probably
going to want to return an integer here, as well [SOUND], and properties are capitalized.
So, just as methods are capitalized, just as class names are
capitalized, properties are capitalized [NOISE]. We put an open and closed curly bracket. And I'm going to talk about the syntax for
both things that we can do within a property, and then we'll get rid
of the one that's just crazy. Okay, so the two things we can get for property, the two things we can do for
properties [NOISE] is read them, we say we can read the
property we implement the read capability for a property by providing a get
accessor, and we can set the property. So basically we can get the value of this
state information, sorry about that, this state information
numSides, and we can set the information. So I will implement both and now I get rid of
the one that's dead wrong. Okay so to get numSides, what we're really
saying is, go through that picture, I am accessing the property and you should tell
me the information that you have hidden in
your core. And so that is definitely numSides. So we need to somehow get the value of the
numSides variable and we get the value of variables by just putting
the variable name. But now we need a way to actually return
this to the person, the consumer of the class who's
trying to access this property. And the good news is, programmers are crazy, but sometimes, we use appropriate
words. So if we want to return something, we use
the word, return. And so, by putting return numSides when someone tries to
access this property, we can just give them what is in that
property. So that's get, that's actually get the
that's the read. Find out. There is a right, possible in properties,
and it's done within the set accessor. And so the way we do it is we say numSides
equal. So we're trying to set the value of this,
field. So numSides is equal to something, and that something is a special keyword called
value. When it's time, oh, you've actually
already seen this. Right?
When you did, bear.active equals false. That false part, when you are accessing a
property, you are accessing the set accessor for the active
property, in the inside the property which we didn't look
at, but inside the property that false that you were, that
you had on the right hand side of the equal was, actually
called value inside. So that's how, we'll see this again, don't
worry, when we implement the x and a stuff
because boy, it makes sense to actually find out the
number of sides on a die. But it doesn't make any sense at all to
let a consumer of the class change the number of sides on
the die, once it's been created. What are you going to take a file and, you
know, make new faces on the die and color them in with
magic marker or something? No, definitely not. So this particular property, it only makes
sense for it to have a get accessor. And we'll add a comment, get the number of
sides. [SOUND] Now the only property we said we needed
was, the topSide. So lets do that as well [SOUND]. And just as for numSides, it only makes
sense to have a get accessor for topSide. If you could roll a die and then reach
over and turn it so you got a better roll, dice games would not be
nearly as interesting as you might expect. And if you want to you know, travel to Las
Vegas and try that at the craps table, you'll probably
get in trouble from the Casino. Okay, so just get.
We can look at the top side but we can't change it.
Okay, so same exact thing [NOISE] as above except this time we'll return top
side instead, and of course, we will add a
comment [NOISE]. So that either somebody reading the source
code or the documentation we generate, clearly
indicates what gets done. Okay. I'm going to F6, so I can build, and I can
F5, or Ctrl+F5, because this is the Console App
and it's not exciting at all. So you might think that we should
definitely test this properties right now. And while I would agree with that, the
problem is we don't have any constructors yet, so
we haven't created any die object yet, so we can't access the properties of a non existent
object. So, we will actually start testing these
properties in the next lecture and speaking of the next lecture this is
the end of this one. So we've done our design for the die class
and we have implemented the fields and properties, so we've handled
the state part of what we need from state behavior and identity. And next time we'll actually build a
couple of constructors for the die class.