I'll just say if you are feeling crunched for time, you can completely skip this page. It's talking about the difference between "is-a" relationship, which we just described with inheritance, and "has-a", which has nothing to do with inheritance and is actually covered back in Unit 5 if you look in the course and exam description although I don't remember if we actually talk about it, but it's not actually really that important. We don't actually use has-a much. Anyway, I'll walk you through it briefly, but again, you can feel free to skip this completely if you want to move on along with your students. Is-a versus has-a. We said a car is a vehicle because all cars are type vehicles. Here they're defining a different relationship which we would use in trying to figure how we're doing class design, which is maybe a has-a relationship. They're using an example of a course, say algebra and a course period like first period, second period, third period, and this is a different unit course diagram type that you don't need to know and your students don't need to know, and basically, they're talking about a one-to-many relationship or a zero-to-many relationship which is the star, which basically means an algebra course can be in zero or more course periods. It can be like maybe you don't have algebra scheduled at all, it's in no course periods, but it could be Course Period 1, could be Course Period 2, etc. Basically, what has-a means is they're usually design options. If I wanted to talk about designing some software that represents courses that we're teaching and the course periods in which we have them scheduled, I could choose to make a class called Course that has an array list of all the periods, for example, or I could choose to have a class called course period and in each course period, I would keep track of the course name that's being offered in there and maybe also the period. So this is just saying there are multiple ways you could design these things and neither of them have anything to do with inheritance, it's all about like there's relationships between two classes that we're designing. The way they're talking about is that how do you know if something is-a inheritance or it's a has-a? It is true, the substitution test is the thing it says. If you have a book class and it has subclass of comic book, is a comic book a type of book? Yeah. So you can substitute comic books for books. So what they're really saying if we were drawing our diagrams, again, book is our superclass, comic is our subclass, and the way I prefer to think that is it like, "Are old comic books, books?" Is there anything that a book has, a comic book would never have? Not if we designed book generically enough, probably it has an author, probably it has a title, may or may not have an ISBN number, I don't know, but all comic books would be books. It would not be true to say that all books are comic books, there are things about comic books that are unique to comic books. So if you think back to the person and student or person and employee, they're equal. This last programming challenge, first off, let's just notice as do some research on an online, find out what things the story about books. If you have time, this is a cool, great class design, like what kind of instance variables would we keep about this? Which things would be inherited from another? Class design is not explicitly tested on AP. There are free-response questions that are going to be about inheritance, but they're going to be given definitions and rules to follow, that really is not what is reflected here. This is perhaps a good thing for software developers to be able to do, but it's actually cost us in a very hard thing, and that's a lot to be asking students at this point in their career.
