Here we are, in the second week of the
class. And starting on module four, which is
about classes and objects. Just to let you know the learning
objectives for module four. Here they are. This is the only module that has an
objective about creating. We're going to be designing a class
together at the end of this module. But we'll also be applying the knowledge
you learned by using existing classes that I'll
provide to you. In this module, we're going to talk about the foundational ideas behind the object
oriented paradigm. So here's the big idea. The big idea is that software can be
implemented as a collection of objects that interact
with each other. So, this paradigm is very well suited to
game development because if you think about it, games are
virtual world, where there's a bunch of different
entities that interact with each other. If you're walking along in the virtual
world and you see an Orc, you might decide to interact with
that Orc in a particular way. With your bare hands, or your sword of
massive cutting or whatever. If you see a teddy bear in the game world,
you may decide to interact to that teddy bear in a particular way, so
you might hug the teddy bear, or you might explode the teddy bear, or you
might light the teddy bear on fire, or you'd interact with that
object in some way. And even non-player characters, right, the
NPCs interact with each other. In with you as part of the game world. So there's lots of interactions between
objects or entities in game world, so modeling those game worlds in
our software as interacting objects is a really powerful technique
that we can use. We'll start off with an in-lecture quiz so
you can tell me a little bit about what you already
understand about software objects. Okay. So, software objects have three different
things. They have state, they have behavior, and
they have identity. And we can relate this to objects in the
real world as well. So the state of an object is the
characteristics of that object. Think of yourself right now. You have a number of different
characteristics. You have a height, you have a weight. You have a degree of hungriness, and
perhaps a degree of boredom. How cruel. But these are different characteristics
that you have that potentially change over
time. You might grow taller or you might shrink.
You might gain or lose weight and so on. So the state of an object is really all
about the characteristics of that object. Objects also have behavior. So there are things that we can do to
objects, like we could take a teddy bear and throw
it. And there are things that we can tell objects to do to themselves, so when we
get to XNA in particular we'll tell an object
to, perhaps we tell a teddy bear to draw
itself. And so we don't have to worry about the
details of how a teddy bear draws itself.
We just tell it to do so. Similarly, if we had a deck of cards, we
might just tell that deck, go shuffle yourself and we
don't care how it happens. It's just that it happens internally to
the object. So, objects have behavior as well. They have things they can do or that we
can do to them. And finally, objects have identity.
We will end up or we'll discover that we create objects, as we go along in our
software as our software program runs. And each of those objects lives, if you
will in a different place in memory. And so each of them are distinct from each
other and so they have identity. And that's good too, right. If you are in a traditional classroom and
somebody wanted to call on a particular student,
you can't just yell out the question, you have to
first say which student you mean. And then ask your question. Similarly with objects, if we want them to do something, we need to specify which
object we expect to do that thing before we, sort
of access the behavior of that object. So identity is really important as well.
So all objects have state, behavior and identity.
That's a language-independent, object oriented set of concepts that
really has nothing to do with C#. The next slide uses some C# specific
terminology. So let's actually have a concrete example.
We're going to have a playing card object. And that playing card object is going to
have state, behavior and identity. And the state of that playing card will be
stored in fields. That's a C# piece of terminology, but I'll tell you right now fields are just
variables. We learned in the last module how we can
declare and use variables while the fields in an object are just variables.
Externally from the object the way we'll let sort of consumers of this
object. So the game for example has a playing card
in it and the game needs to know something about the
state of this card. We almost never will let consumers of this
object access those fields directly. That's really bad programming practice.
So instead what we'll do is we will expose, that's the terminology we
use, we will expose that state. Through C# properties if you've programmed
in other languages like Java for example, you've written
getters and setters, or accessors and mutators all the time, in C#
we have this concept called properties, that does
exactly the same thing. It let's us access, read, write or both
particular pieces of state for the particular object.
So, that state. And for a card the particular things we
might store for state are the rank of the card, Ace, King, Queen
and so on. The suit of the card, depending on the
game you're playing. you know, grass, water, fire or perhaps hearts, clubs, spades and diamonds and
whether or not the card is face up or not which would
matter to us if we're actually drawing the card. So, you know you draw a face down card
nobody can tell what it is. You draw a face up card and everyone can
tell what it is. Okay. So that's state, there's also behavior
associated with the object, and in C#, we expose behavior through
things called methods. Other languages used terminology like
method or functions, their methods in C#, and the method that
we'll have for our cargo, will be the flip it
over. And finally cards get their identity when
we create new card objects and that's called
instantiation. So, another opportunity to do an in lecture quiz addressing particularly the
state of objects. So conceptually for our card what we have
is, inside here, hidden inside the card, we have
those fields that we don't let anyone access
externally. And by the way, having the fields and
around the edge here, around the edge here, all of these different
properties and behaviors. Bundling all that stuff together is called
encapsulation, because we've put the state and the
behavior all into a single capsule, if you will, that object that carries all the stuff
around. The other thing that's important, though,
is as we access things like properties, like the Suit property here, or as we call
a method, the FlipOver method here, the other thing that we know is that
the consumer of this object, doesn't know anything about the internal details.
They have no idea how it's implemented. They have no idea what data types the
Rank, Suit, and FaceUp are. There are logical choices, but we don't
know, and so this is another important object oriented
concept called information hiding. The implementation details are hidden
inside the class. So, we can change those. We could change the data type we use to
store the rank of the card, and as long as we didn't
actually change the property, then consumers of this
class, or this object, could just keep using that property without even knowing
that the implementation details changed. And that is fantastic for when we actually use objects in large
software systems over time, because we make changes all the time when we don't
break the rest of the software. So this conceptual idea of an object where
we have the fields hidden inside and then we sort
of have this boundary of stuff that we expose to
people, consumers of the object to use, is a really powerful object
oriented idea that we will see again and again.
Now, I keep talking about objects and classes, and it's a, there's an important
distinction between the two. And so, let's get that distinction nailed
down right now. The class, is actually the template, for
creating objects, the class is not an object
itself. It's sort of the cookie cutter if you will. It tells us what all the cookies will look
like and, you know cookies tend not to have behavior and thus, you know, you have scary dreams or something about
cookies. But it tells us sort of the shape if you will, of the objects that you're going
to create. But it's not an object itself. But the good news is, it's a template. And we can use the class to create as many
of the actual objects as we want. Just as you can use a cookie cutter to create as many cookies as you
want. So it's a template that defines the state
and behavior of each of the objects that get created
from this class. The objects are the actual things. Right? They're the actual things and memory and
so we can have a whole bunch of them. We can have a whole bunch of playing cards
if we wanted to play cards. Playing cards with one card is kind of a
boring game. And even though each card knows, or if
the. Let me put it a different way. Even though the class says that each card
will store a rank and a suit, and whether or not it's face up, each of the individual card objects maintains their
own current information, right. So each of these cards has a rank and a
suit, and whether or not it's face up. But those ranks and suits, and face ups
can be different. Right? We can have a King of spades as well as a
Queen of hearts. And, they're still all cards, they're just
different instances of the cards. So, classes are a template, objects are
the actual things that are instances of, that's the terminology we use, that
are instances of that class. Now, when we talk about class design. Not actually using classes externally as
consumers of the classes. But actually designing classes and
understanding how they're implemented. We often use this notation that I've
provided here. And this notation includes the class name. The fields. So these are the things that we're always
going to make internal to the class. The properties for the class. So these are the things, these are the
ways that we're going to provide external consumers of the class to
actually find out about the state. And finally methods. That behavior stuff, that we've been
talking about. This notation is called UML and clearly, there's an in
lecture quiz about UML and what it means. Despite what you might have chosen in that quiz it stands for Unified Modelling
Language and it's really the most commonly used notation these days for specifying object
oriented systems. Okay, before we finish the lecture because
we're almost done we've hit the big ideas behind object oriented, implementations the whole object oriented
paradigm. And we'll start using it next time.
But before we leave, I need to point out that classes
are not value types. Classes are reference types. Remember in the previous module I said
well, we won't worry about reference types until
module four. Well, here we are in module four.
So, classes are reference typed and really classes are each a data type.
So, you know we had [INAUDIBLE] and float for example. Well, when you start implementing classes,
you're creating your very own data types. And they're reference types, rather than
value types, because. For value types, the ones and zeros at the
memory location for the variable represent the
value of that variable. For reference types, the ones and zeros at the memory location for the value
represent a reference to where the object actually
is in memory, so. People try not to use the word pointer,
but it's just a pointer to where the object
actually lives. So a picture might help. Here we go. So age is an integer variable, so it's a
value type, so the value 17 the ones and zeros
17, in that memory location mean ages 17. The rain message, which is a instance of a
message object that you can read about in the sorry, instance
of a message class, which you can read about in the book if you
choose to, but it just holds the message and let's you
print it and so on. The ones and zeros there, at that memory
location represent 44. But 44 is not the value. It's a pointer, or a reference to a different place in memory where the object
actually is. So that's that distinction between
reference types and value types that I said we'd get to in this
module. Okay, to recap the object oriented
paradigm not just C#, just object orientation in general, provides classes and objects
where classes serve as the template for creating
objects. And objects have state, behavior and
identity. We also learned that objects interact with
each other in the software that we write to actually
implement our game, whatever else we're doing with
our software. It might not be a game, how sad. Next time, so this was all conceptual
stuff, important foundational conceptual stuff to
understand how object orientation works. But next time, we'll actually dig in and
start using this stuff in a C# program.