In this lecture, we'll start by talking about objects. But before we discuss the details, you could think about objects as representing tangible things in the game. Ships and asteroids and weapons and projectiles and teddy bears, the things that we have in the game. And, objects are really a model of those tangible game entities. Let's talk about the three things that objects have. First, objects have state, and state is the characteristics of that object. And for our ship example, the state might be – where is the ship in the game world? How much is the ship rotated? What is its current velocity? And so on. It's the current characteristics of that object and those characteristics might and probably will change as we run the game. The second thing, all objects have is behavior. What can we tell the object to do and what can we tell the object to do to itself? For a ship, we might say, "Well, we want to rotate the ship." And so, we provide input and we rotate the ship. We might want to apply thrust to drive the ship forward in the direction it's currently facing. We might want to tell the ship that, "You know, after your useful lifetime, after 10 seconds or three minutes or 10 hours or whatever, destroy yourself." And so, there are behaviors, there are things, that ships will do either in response to user input or all on their own. And those are behaviors of the object. Finally, all objects have identity. If our system is a bunch of interacting objects, then we have to be able to tell them apart. And so, each object has their own identity. And it turns out that in practice, the identity of the object is the memory address of that object. Now, you should do it in video quiz to tell me that you understand what we just talked about. All right let's talk about an actual example. Let's talk about a playing card. A playing card has state and for the example here, the playing card has a rank like ace two, three all the way up to king. It has a suit and we'll use the standard card suit. And it also has whether or not it's currently face up. I said that the state can change over time as we play the game, you're probably not going to unless you're a cheater. You're probably not going to change the rank in suit of a card, but you certainly may flip it over or flip it so it's face down and so on. And so that particular piece of state might change as we run our game. Now, state is stored in something called fields in C-sharp. And I'll tell you right now, fields are really just variables. We've learned about variables and so fields will be variables inside an object. We don't actually let entities outside of the object see our field if we're good programmers. And so, we will let those entities, we'll call them consumers of the class. We all have those entities access properties, to get at the state of a particular object. And then a playing card might have behavior too, right. It might be that we can flip that card over if in fact, we're going to store whether or not it's face up. And so, that behavior in C-sharp is implemented in something called, "A method." You might hear people talk about them as functions, but they're really called methods in C-sharp. And finally identity, every playing card will have identity. When we create a playing card object by instantiating it, that's the word we use when we say we've created this new object from the playing card class, then it gets a memory address. And that's how a playing card gets its identity. Now, you should take another in video quiz to see if you understand what I just said. So here's a pictorial representation of the card object that we've been talking about. On the inside, think of it as the donut hole, that is the set of fields, we're going to use to store the state of the object. It's all hidden inside in the core of the object and those are the fields. Around the outside, we have the properties that we're going to let people access to find out what the rank of the card, the suit of the card, and whether or not it's face up. And we also have the method to flip over the card to, so that's behavior, right. The first three are properties, letting consumers of the class access the state. And the fourth one is a method to actually implement behavior of the playing card class. There are a couple of important object oriented ideas that you should have before we continue with the lecture. The first one is this thing called encapsulation and I've represented that with this magenta circle around the outside of the card. The idea is that we have encapsulated, we've put in one place, in a little capsule, both the data that stores the state and the behavior of that entity. We've encapsulated the data and the operations or methods together. The other idea is something called information hiding. The consumers of the class get access to the properties and behaviors through the outside through that magenta circle on the outside. They have no idea what fields we have or the data types of those fields. They have no idea how we implemented the flip over method. All they know is how they can access the properties and the behaviors. And so, you can think of this as a black box even though it's drawn as a magenta circle. Think of it as a black box because all we can do is provide inputs and get outputs and they have no idea about the internals. And that is information hiding. Okay. One of the important ideas here is, what's the difference between a class and an object? Well, a class is the template for the objects we'll create. The class specifies the fields and properties and methods that any object that we create from this class will have. If you want to think of the class as a cookie cutter that determines the shape of, and behavior, that's kind of a scary cookie, but the shape and behavior of all the cookies we're going to create is the template. It's the cookie cutter that says what all of the cookies will look like. An object is the actual thing that lives in the game, it's an instance of the class. And so, when we create an object we take that cookie cutter and we make a cookie. So, think of the object as a cookie and that's the right idea right now, each object because they're in a different place in memory, because they have identity. Each object stores their own state. That's why we can have playing cards that the king of hearts in the ace of spades and so on both in our game, even though they're both playing cards. Objects have their own state that they maintain as we go along. This is the more standard representation of a class. This is our playing card class and it expresses the fields, properties, and methods that any objects that we create of this class are going to have. And this representation is called UML which stands for Unified Modeling Language. Now, that I've told you that, you should go do an in individual quiz to tell me if you understand what UML stands for. Before we leave this lecture, I want to point out, that any variable that is declared to be of a class, like a card is actually a reference type. The value types that we already talked about like numeric data type, the bits in memory are actually the value of that variable. The bits are an integer value and we can interpret it as such. For a reference types, the bits in memory are actually a memory address. They refer to a different place in memory, where the object actually lives. Here's a pictorial representation of that idea, of course, it's not exactly accurate, but as you can see value types just hold the value right there in that memory location. But reference types, essentially point to a different location in memory. To recap, we learned some really important ideas in this lecture, and those ideas are; that we can define classes that are reference types, that we can use to instantiate objects that have state, behavior, and identity. And those objects interact with each other to actually implement our game.
