In this lecture, we'll implement inheritance in a C++ Console App. This is the class hierarchy for the inheritance we're going to implement. At the top of the class hierarchy, we have a family member class that implements a constructor, a destructor, getters and setters for height and weight, and a HaveFun function. We have a gamer child class that implements a constructor, a destructor and its own version of the HaveFun function, and we have a geek child class that only implements the constructor and destructor. Let's go see how we can implement this class hierarchy in our code. We'll start with our implementation of the family member class, the top of our class hierarchy for this example. Our family member class has a couple of private fields, remember variables called height and weight. We have a constructor where we pass in the height and weight and use that to create our family member object. I have a destructor for family member. Remember back in our console apps lesson from the previous course, I said that when we got to inheritance, it would be important for us to implement destructors. Well, here we are in inheritance and it is important for us to implement destructors. We'll talk about the need for this virtual keyword in front of the destructor when we talk about polymorphism in the next lesson. We have a getter and a setter for height, a getter and a setter for weight, and a function called HaveFun that makes the family member have fun. We have marked this function as virtual because we know that one of our sub-classes or child classes is going to want to replace whatever functionality we have in our HaveFun function here with custom have fun behavior in the child class. Implementing a function with the same function signature in the child class is called overriding the function if we've marked this function here in the base class or the parent class with the virtual keyword. If we don't mark it with the virtual keyword, then the child to class function with the same function signature actually hides this one. But in general, we're going to find that we want to mark our functions that might have overwritten behavior with the virtual keyword so that we can actually use the overriding mechanism. In the implementation file, you can see our constructor is as expected. We use that member initializer list to initialize our height field to the height parameter and our weight field to the weight parameter. Our destructor doesn't do anything though it will when we start talking about polymorphism. The getters and setters are just as you would expect and for a family member, the default having fun behavior is I'm writing code because that's what most family members should do to have fun. This is our family member class and it's going to serve as the root of our class hierarchy. But as I showed you in the UML diagram, we're going to have two child classes that use family member as a parent class. We'll look at gamer first. Notice we have to pound include the header file for family member because we're inheriting from family member. You've seen this before. This is the new syntax that says family member is my parent class. Specifically, this part says family members is my parent class and this base class access specifier controls our access to the protected, which we haven't talked about yet, and private member variables and functions of our parent class. If we use public for our base class, then everything stays the way it was in our base class. Public member variables and functions stay public, protected member variables and functions stay protected, and private member variables and functions and stay private. If we put protected here, then public member variables and functions in our base class become protected and protected member variables and functions stay protected, and finally, if we put private here, public and protected member variables and functions become private instead. There are lots of cases where you might want to use protected and private. But throughout the examples in this course, we're always going to use public as our base class access specifier. You should think about this as in our gamer object, we have a family member sub-object. Putting this base-class access specifier here determines how we access the member variables and functions in that sub-object. We have a gamer constructor, we have a gamer destructor, and we're overriding HaveFun. We say we're overriding HaveFun by including the override keyword. This function is still a virtual function because the function in the base-class is a virtual function. You can mark it as virtual as well if you want to be particularly clear about the fact that it stays a virtual function. This is a matter of taste. Seeing the word override already tells you it's a virtual function. Understanding how C++ works would tell you that this will be virtual as well. If you want to just be really explicit about it, you can just put the virtual keyword there as well. Whether or not we mark this function with the virtual keyword, if we were to derive another class from gamer, that other class could also override the HaveFun function. In our gamer implementation file, you can see that our constructor here is actually calling the FamilyMember constructor. It's calling the constructor for our parent class. In general, you're going to want to do that because you want to have your parent class sub-object, that's contained in our gamer object get initialized in an appropriate way. That's what the constructor for FamilyMember does. The first thing we want to do is call that constructor to initialize our sub-object. If we had other things that we wanted to do in the constructor, which we'll see in the next lecture, then we would then put it in the body of this constructor. But we don't have anything else we need to do in the gamer constructor, so we'll just leave that body empty. We have a destructor that does nothing. Here's where we override the behavior of HaveFun because the gamer object wants to say, "I'm playing a game, " rather than, "I'm writing code." I will freely admit, I know from personal experience that you might like to both write code and play games, but for this example, we'll say a gamer doesn't like to write code. They like to play games to have fun. Notice, we don't put virtual here in our implementation and we don't put override in our implementation. Those go in the header file, not here in our implementation file. The last class we have to look at for this example is geek. The header file for geek says, I am a child of FamilyMember, and I'm using that public base-class access specifier. I have my own constructor and I have my own destructor. I'm not overriding the HaveFun function. In my implementation file, I call the constructor for my parent class, and then there's nothing else I need to do in this particular example and my destructor does nothing. How does this all work? Here, in our main function, I'm going to create three different FamilyMembers. I'm creating a FamilyMember object and putting it into a FamilyMember variable. I'm creating a gamer object and putting it into a gamer variable. I'm creating a geek object and I'm putting it into the geek variable. Then finally, I tell each of those variables to have fun; TheFamilyMember, TheGamer, and TheGeek. When I run my code, you can see that our base-class or our parent class, the top of the class hierarchy, TheFamilyMember, says, "I'm writing code." TheGamer, remember, overrode the HaveFun function, so the gamer object prints, I'm playing a game. Finally, the geek object, which didn't override the HaveFun function, just inherits that function from the parent class. When we call HaveFun on a geek object, it doesn't have an override of that function, so it goes and finds the function in the base-class sub-object and executes that function. That's why it says the same thing as the family member objects says when we tell the family member to have fun. To recap, in this lecture, you learned how to implement inheritance in a C++ console app. You also learned how a child class can override a function it inherits from its parent.
