We'll start this lecture by talking about objects. Before we talk about the details, you should think of objects as software representations of tangible entities or things. Ships, asteroids, projectiles, entities that we might want to include in our games. Every object has three things. Every object has state and state is the characteristics of the object. If we're thinking of a ship, that a ship has a certain amount of fuel, it has a certain velocity vector, it has a certain angle at which it's rotated. There are particular characteristics that that object has, and those characteristics are called state. Every object also has behavior. Behavior is something that we can tell an object to do, for example, we could tell our ship to rotate. Sometimes we think of it as something that we can tell an object to do to itself. We can tell our ship to refuel itself or something like that and when we talk about decks of cards later will say the deck should shuffle itself. Those are behaviors, those are things that the object can do, we can tell it to do or we can tell it to do to itself. The final thing an object has is identity. Identity makes it so that we can distinguish this ship from this ship. It gives us a way to distinguish between objects. In practice, the software representation of an object lives at a memory address, so different objects are at different memory addresses. I know we've been talking about a ship, but let's talk about a playing card. What's the state of a playing card? Well, playing cards have rank, aces through king, suits, and whether or not they're flipped over or face up. We can store the state in good object oriented design in something like C plus plus. We store the state in fields, and fields are really just variables that are available throughout the class, not to just in a particular function like we've been using so far, or that we have generally been using so far. We don't however, want people external to the class, to be able to just access those fields directly. Instead, we provide them with things that are called the getters and setters or accessors and mutators. People used those two different pieces of terminology and I will use those two pieces of terminology interchangeably. But they allow consumers of the class, somebody outside the object, to either access state by saying, "hey, what's the rank of this card?" Or by being able to set pieces of the state, which we actually won't do in our card example. The next thing is behaviors, what behaviors does a card have? Well, the most obvious one is that we can flip a card over. If it's face down, we can flip it over and now it's face up. Behaviors are implemented through functions. Now I will say that getters and setters are also functions, but we tend to think of them as distinct from behavior functions because they're really just designed for accessing the state of the object. It's also the case, as we can see with this example, that calling a flip over function will in fact change the state of our playing card. If it's currently face up and flipping it over, we'll make it face down. General behavior functions also are likely to change the state of our object, but there are distinct from getters and setters in the way people think about it. Finally, Identity, so each object that we create from the class. I'll talk about the distinction between classes and objects before we're done. But each time we create one of these objects, which is called instantiation, that object gets a place in memory to live, and that gives it its identity. Here's a conceptual picture of our card object, the way we've been thinking about it. At the core that inside part, the doughnut hole, or that has stuff in it, is the field that we're going to declare for this particular object. We have a boolean that will tell us whether or not their card is face up, and we have its rank and suit. Then we have the getters and setters spread around, we can get the rank, we can get the suit, and we can ask its face up. For getters, and that's all we have in this particular discussion, If the getter returns a piece of state that's boolean, it is general convention to say, is instead of get, and that actually makes it so that when we build boolean expressions, which we'll learn about in the next course in the specialization, as we build boolean expressions, they'll be more readable. Finally, we have the one function that is a behavior function, the flip over function. This is a picture of a card object. There are two important ideas that go along with the object oriented paradigm. The first is called encapsulation. As you can see, I now have a Magento boundary around by object. Encapsulation simply means that we put the data and the operations, those getters, setters, and functions that affect the data all in one software entity. We've encapsulated them inside this shell to make them all together. That's one important object or an idea is encapsulation. Another really important object-oriented idea is information hiding. Now, as you can see, I have shaded all the internals of this particular object and that's because somebody outside the object can only interface with the object through the getters, setters, and functions and they don't know anything about how the implementation is implemented on the inside. They don't know if we have three fields or 20 field, they don't know the code that is contained in GetRank, they don't know how the flip over function is actually implemented and this is great. This is a huge idea because if we do good object-oriented design and we use information hiding, then say we have tons of other pieces of code that use my object. If I change the guts but I don't change the interface, all of those things still work and that's fantastic. For maintainability, it makes it so we don't have to worry about changing the internals because everyone interfaces with this object through the interface, through that boundary of the object. I told you, I would tell you about the difference between classes and objects before the end of this lecture and I've been using those terms interchangeably, but there is a precise difference between them. A class defines all the fields and the getters and setters in the functions for any object we create from the class. You can think of this as a cookie cutter. We want to make cookies and the class defines the shape conceptually of the cookies. Cookies with behaviors might give you nightmares but just think of the metaphor as this is the cookie cutter will use to make cookies. It defines the shape, the field, getters, setters, and functions for any cookie we make. An object is actually the real live instance of the class and you can think of it as the cookies we make with the cookie cutter. We make a number of cookies and then the cookies can interact with the real world and wicked. Well, the software world and we can interact with them by binding them or wherever we choose to do with our cookies. They'll interact with each other. We throw that at each other and they'll break and all stuff. The objects are the things that we actually put into the real world. Well, the game world by instantiating the class, that instantiation thing. I will point out that each cookie holds its own state. We can have two ships, that this one has a half a tank of fuel and this one is full and they're going in different directions and they're rotated at different angles. Or we can have two playing cards and they have different ranks and suits, that's the only way you can build a card game is if all the cards aren't the same. When we create an object, we are giving it embodiment in the game world and it will now maintain its own state. This is actually a more common representation of a class and this is in something called the unified modeling language or UML. At the very top we have the class name, and then we have a set of fields. In UML, we give the name of the field and then the data type. That is exactly opposite of the way we declare variables in C plus plus, but we're going to use real UML notation when we use UML notation and the name of the field comes first. These are the three fields that we're including in our card class. Then at the bottom, this says methods and I keep saying functions. I will say that people call these behavior implementations in C plus plus either functions or methods, those two terms are interchangeable. I will consistently call them functions, but Visual Studio, which are used to generate this UML diagram calls the method. But those two words, functions and methods mean the same thing. Then we list each of those functions that we have, the three getters and the flip-over behavior function. To recap in this lecture, you learned some important object oriented ideas, you learned that we have object-oriented classes that we use to create object, and you learned that those objects are the things that we can actually have interact with each other to actually implement our game world.
