So, in other words, it's a way of expressing in the grammar of the computer programming language, just like in natural English or Chinese or Arabic or any language we have grammar, and computer programming is also a language with a grammar. So sub classing is a grammatical formulation which lets us express relationships. So I can say that I have a set of relationships in my business domain, which is involved in my UML diagram. So I have an employee, and an employee can sub class down to a manager or a worker. And a manager could be a line manager or an executive manager, and a worker could be a production worker, warehouse accounting, you know that they can be different kinds of roles in the company. So the purpose of inheritance now we understand is to express it gives us an expressive syntax, an expressive formulation. So another programmer looking at our code will immediately understand what's the purpose of it. And as we write more and more complicated programs, and we have the job of making sure that other programmers later can come in and support what somebody else did if we use and by the way, I'm recording all of this with my with my honorai. I'll print out the dictation later. I'll send it out to some people like to read as well as listen to things. But the purpose of inheritance, and by the way, there's another thing we're going to talk about later, called composition. There's there's two ways to wire up objects so they can talk to each other. There's inheritance, so there's composition. And if you understand that, then you understand when you're making a method call, what's the right way to structure that method call. Or if you're using inheritance, I can inherit, let's say if I'm a type of object called an instructor and I sub class, maybe we have an abstract super class called a perfect instructor, and I sub class down to just like a regular work a day instructor. So that is a sub class, and that's an inheritance relationship, but I don't have to just inherit from a class. What's a class? A class is a information representation which contains data, fields and and methods, it does not contain unique identity. When object contains unique identity, we make an object from a class. Now we go from class to object, we get a unique thing in the world. So a class, in a sense, is like a meta or a sort of a, sort of a spiritual or like a platonic description of something that exists in the world. So anyway, I can make a subclass in my class hierarchy. When I say class hierarchy, that's just a UML diagram. When I'll draw a few pictures on the whiteboard later, but a class hierarchy is just a UML diagram that shows all my classes and how they connect to each other. To get either thing with me, you can connect classes by inheritance or composition. And there's another thing we're going to be studying. After we go and study our polymorphism, we're going to be studying something called interfaces. And interface is a super class, but it does not tell me how to do things. It tells me something needs to get done. It doesn't tell me how to do it. So what's the benefit of that? Well, let's say you're my Asia programming team and you're my European and this is the way things were at IBM, right? We get programming teams all over the place, and you guys need to work with classes that they are going to write, but they haven't written it yet. And you need to make your classes work with classes they're going to write, but they haven't written yet. So there's a way around that. As the information architect, I'm going to tell them that this set of classes has to obey a certain interface, which means it has to deliver certain methods. How are you going to deliver the methods? Well, that sort of depends on the exact executional context of what's going on when the method is delivered. So again, going back to The Legend of Zelda and video games, by the way, I encourage people to sometimes try programming a very simple interactive game, even if you don't have graphics and stuff, just a text console based game, because it is a very good way of drilling your thinking and understanding how to deal with things real time in accordance with, like, a user's unknown at design time. You don't know what the user has been asked for, but you have to accommodate it. So Zelda is walking around carrying their sword, and they, you know, pick up this magic stone, and they like hit the magic stone against the sword, and the sword now has some power, so Zelda can now go under the bridge, and the troll is going to show up and go, Why not letting you go across the bridge? Don't ask me why they always kill dragons and stories. I never thought that I like I've never been bothered by a dragon. I probably liked them if I met them. But apparently in video games, you're constantly killing dragons. So the point is, the Zelda hero might be able to kill the dragon if their sword had the right kind of magic power. Anyway, that's an example of where you might need an interface to specify, then a subclass should deliver a certain method, but how it does that? That's going to be when we're calling it. That's something we'll have to decide downstream anyway. Let's go ahead now. That's probably enough theory. Let's go and start working on our first workbook, which is inheritance. And I'm going to keep this open, and I'm going to go through the the lab work, but I'm going to sort of note a few theory topics here as we're going along. And I'm doing this because the college is sort of created. Was very good, like they do, very nice material. It's great. But I've sort of observed in past terms, sometimes at the end, or when I look at the final exam or the final project, I get the feeling the students may not have gotten enough of a sort of an intuitive understanding of the concepts. And with object oriented programming, there's actually a lot to get. So anyway, you know what? I'm gonna link this directly to your lab book. I'll put it up there in George in the Learn thing later on, but for right now, just so you have it, we'll also link it to your lab book.