9.1 is broken up across two separate pages. They're both really short, but again, that's how you'll see them as the teacher and the students will see them. So I'm going to break these videos up this way. We'll get introduced to this concept of inheritance, which is a key component of object oriented programming and where we get some of the benefits that are going to outweigh some of the crazy overheads of, why do we have to learn all this stuff about class design and things like that? But I'll give you a bit of extra help in getting going on this. Almost everything here is really good. There's a teeny thing in 9.1.3 that you don't need, but I'll point that out. So talking about inheritance. There's two paragraphs of, looks like dense text here, actually, all of this vocabulary is important and it's worth it to break this down sentence by sentence with your students. Inheritance will be something that is familiar to them from maybe Biology or family diagrams, and it's pretty related, but there are some things that are a little bit different. Like you can actually only have one parent in an object oriented programming inheritance tree, which is obviously clearly weird if you're thinking about families. So there's some important things here, but inheritances, you inherit attributes from your super or parent class. Again, parent I'll prefer we tend to not like to say that, we say the super class because it's got too much complicating things with thinking about real parents. But we have superclass and subclass, and those are generally preferred over parent class and child class. However, there's some really important things here, and we're going to be talking about the is-a relationship. The example I give here is in a particular diagrammatic format called UML, which is I think unified, they'll tell you what it is. But anyway, we don't have to know that for APCSA, and honestly, it's not something we bother to teach except maybe just mentioning it in passing in a lot of university settings. But what this is basically saying is, this is a class diagram that the superclass's vehicle, which they label here as parent class, I would prefer superclass, and then car and motorcycle are subclasses. The way we say that these are inherited is, we can say that a car is a type of vehicle and a motorcycle is a type of vehicle. So if all cars are of type 'vehicle' then it can be a subclass. Now, not all vehicles are cars, so that's why vehicle is the parent or superclass. That said, you can google and find lots of different examples and I think your students really need to see more than one, so here are a couple of good ones I found. Animal is a great class to talk about. Whether it can be a dog is an animal and a cat is an animal. A persian is a cat, in the same way a cat is an animal, so you can have multiple levels. Aircraft here, we've got civilian versus fighters and then to particular types, or this is one of those class diagram that you do with the guessing game, animal, vegetable, and mineral. So you can get some more examples, lots of things you can google on for that. One thing that I will have you note, and again, this is different than the way we might diagram family trees, is that the arrows generally are going to go up. Sometimes we don't actually even include the arrows. If they're official for UML, they're supposed to be going up. You notice the example on the right doesn't have arrows really at all, but they definitely don't go down. So that's something weird, but it's not terribly important. Your students aren't going to need to draw them, and if they see them on exam, they're not going to be worried about arrows. So there you are. 9.1.2 is very simple, it just says basically, "How do you say in Java speak that one subclass extends a superclass or is a subclass of a superclass?" It's really easy. Again, we say public class car is the type of vehicle, we say extends the class vehicle or motorcycle extends the class. So just that one word, extends, and that by the way, is going to be on the free response question. Again, it just tells you just memorize that. It's the subclass extends the superclass. It's just like with vocabulary we need to. Now why use inheritance? There's a darn good question. No, it's actually great in two ways. So first off, this whole idea of that all cars are a type of vehicle basically means that we can define some data that we always keep about all vehicles and we won't have to replicate that down in the car class. We can reuse that data and some behaviors or methods from that. So that gives us some generalization. But we can also do specialization. As we're going to find out later in the subclasses, we can say there are some things that are particular that just cars have or that cars do in a specific way, and we'll be able to do that with object-oriented inheritance as well. So here's another example they bring up again using a UML diagram, and this is useful, note like a person class. We might say, look, all people that we're going to keep track of have names and addresses, but a customer is a type of person. Okay, so it's a subclass. But for our customers, we keep credit card info. We don't keep credit card info maybe for all people but customers, we do, that's important. Employee is a person as well, but we don't keep credit card information about our employees. We might keep their ID or might keep their pay rate or whatever. So you could even brainstorm our students are in here. What are things that might be true that we would want to keep of all people? What would be particular data that we would keep only for specific subclasses of people? Again, there's no one right answer to any of these. It's about who you're actually designing the software for and what it needs to do. Then there's a very simple interactive activity. Literally the only thing students do is type in those two words to make the student class extend person. The one thing I dislike about this is the way they're "testing it." Isn't even going to be understandable to the student because they're using this weird Java stuff that where you can say S instance of student, we don't need to know or use this ever, and so I think this is lame. I could probably just skip it and you could work on it. We're going to have multiple more programming experiences where they're going to write something class extends something else, so you could skip this.
