What we are seeing here, by having one class type, Weapon, that is a class type, by having one class type contained within the definition of another class type. A Weapon object contained within a Wizard class, is a relationship between classes that is called containment. Of course, it is often colloquially referred to as a ‘Has-a’ relationship, in other words, our Wizard class has a weapon object. The class are separate but related in that a Wizard has a Weapon. This is useful in a number of ways, the most obvious being that of abstracting or hiding away code. In other words, we concernedly take all the code from our Weapon class and simply stuff it into the Wizard class and avoid having this has-a containment structure. After all, what is so difficult with putting the field, WeaponType of type string and the method UseWeapon() in our Weapon class, just put those in the Wizard class, right? They are pretty simple. Well, nothing is wrong in doing that, right? We can easily do that. I will even show you. Just remove it from our Weapon class. Put it right there. That ruins our references in our RPGController right now.
Just to show you now, it is no longer going to be accessible this way, right now that we have the Weapon type and the UseWeapon() method in our Wizard class. We have to bypass the weapon object. We no longer have the weapon object as a field in the Wizard class, so we just remove that reference. There is nothing wrong with doing that. I am just going to undo this really quickly and put it back in the Weapon class and fix references there. Make sure that the weapon is back there and we can certainly do that. There is nothing wrong with that, but especially when your code starts getting larger and larger as it wants to do, it becomes very useful to box it all up into separate classes and separate objects. Therefore, so that you only really need to focus on a few lines of code at a time. In other words, you can imagine that the actual implementation details of how a Weapon works, this stuff right here, could be many, many lines of code. By stuffing that all into Wizard class, it would be an awful a lot of code to look at. We are just interested in getting the Wizard to have a weapon, use the weapon and so on.
We naturally abstract information away all the time as a way of coping with all the information streaming at us from all directions. For example, when you turn the ignition of your car, you don't need to be made aware of how that entire starting process really happens underneath the hood; sparks, pistons, explosions, whatever. In that context, you just want to turn the key and expect some simple end result. Abstracting a way the details between the guts and the machinery so you don't think about it. That is a big part of the use of creating these class blueprints and multiple levels of containment in Object-Oriented Programming. Another thing is by having separate classes, we are not limiting a Weapon being used only by a Wizard. We can create another character type and give them their own Weapon based on the same class blueprint, alright. I will show it.
Imagine we had not just a Wizard. We can have a Knight. Knight is perfectly capable of having its own weapon. If we had the code for Weapon in the class Wizard, it wouldn't make sense. We have to give a Knight a Wizard. In this case, by having the Weapon class handle all that Weapon code, we can give him or her a weapon, as well using the same type of code, and here in our RPGController, we can do the same thing. There you go. He has a weapon and we can say Sword. Sword, Sword, kind of funny word huh? Give the Knight a Sword. I won't output to Unity because I am pretty sure you will know the result. Now, as I mentioned a few videos back, there is this dual nature in Unity that has its own OOP type component-based interface. Unity has its own implementation of C# OOP structure that you have access to as a programmer.
For now, we won't worry about much in the way of creating classes to handle multiple instances of objects in our game. Instead, we will mainly use what we are learning about C# and OOP, pure C# and pure OOP, going forward, to better understand the Unity API, which we begin to understand surely. The next video actually, using what we have come to learn about OOP in order to navigate Unity's API. By API, I mean, its codebase. Its collection of classes, fields, methods, and so on. In order to better understand the code we already wrote, for example in our prototype game project, and also be equipped with enough understanding in order to complete the project and move forward, creating our own solutions to coding problems that we will face as we are creating games. This is very useful right now, understanding this OOP nature of C#. You can't really go through Unity without better understanding it, even though Unity has its own way of abstracting away that OOP nature. In the next video, we will look at the Unity API and a little more about the C# OOP that we have been covering so far. Alright, you have been doing great. I will see you in the next video.
Lesson 21 - "Has-A" Object Containment