Now, among the things that should be in our toolkit for doing our programming is inheritance. Inheritance is a reuse mechanism. Recall, all along, I keep telling you, reuse is, if you want, this is the golden bullet in software development. You don't want to write original code. You want to reuse existing code that's well tested. Inheritance in jargon terms uses what's called pure polymorphism which I'll talk about later. getting ahead of myself. That's going to use what's called the virtual function mechanism. and it's a, a different scheme than you would find in some other languages such as Java where pure polymorphism is the default. An inheritance also is a way to build a typing structure and remember, C++ tries to emphasize strong typing. Strong typing is very good because it allows the compiler to deduce things and to enforce correctness. An OOP is at the heart of the heart of OOP programming, object oriented programming, is inheritance. So the original languages like Simula 67 and Smalltalk were the first languages that really got going with things like. Inheritance and showed how it can be used to create objects, build objects, build a type structure do reuse and provide dynamic function calls that are basic, that are at the heart of pure polymorphism. All mechanisms that are very, very useful if you are going to build large, large pieces of software. When you have an OOP, an object oriented programming design methodology, you have a, a design step in the design methodology And, you need to decide first on what are appropriate set of types. You, you don't have a predefined set of types. You don't have to make everything be entered double or char as you would in C. You try to build types that are appropriate to your problem domain. So in hex you have a problem domain that's analogous to a graph. So you might want to use a graph as a basic type. You have a hex board so you might have a type such as a hex board or hex game. And part of its implementation may involve graphs. So when you sit down to do a complex problem, like the hex programming assignment, part of your design methodology would be to decide on what will make it easy and convenient for you to implement this hex program. Once you decide on a set of types. You can design in their relatedness. Are types related to each other. Inheritance is a way to share code among classes. And we'll see that in some of the coming examples. Syntactically, any class in C++ (sic). Could be thought of as a base class that can be derived from it. And when you want to derive, you have to derive from it via a, accessibility mode. And, the typical one is going to be public. So most of your benefit is going to have the ability to have a class that is derived, the colon means derived from, and this is the base class name. So that's your syntax. And in effect that means you can reuse all the code from the base class. And you can reuse it. publicly, which means that the base class is a super type for the derived class. Anything that is a derived class member element is of the type of the base class, that's important to the type structure. 'Kay. So again we have a 90% role here you know it's, unimaginable that anybody would know everything in the C++ language at this point. It's just too large a thing. so I love things where what you know is going to be the essentials in most of your work. So if you know nothing else in the inheritance stuff, you want to know about public inheritance. All the other stuff is poof. It's relatively little used. If it was abandoned, it would not be important. So what you really want to know about inheritance is public inheritance. It matches the 90% rule. Everything you learn about public inheritance will be applicable to what you do. Private inheritance which is the the other main characteristic that gets used, is used less than 10% of the time. And, in private inheritance you have what's called the LIKEA relationship. Where there isn't sub-typing. So, public inheritance is a method of sub-typing. Private inheritance is just pure code reuse. And code reuse is not quite as important. I means it is useful, you don't want to throw it away but it's not dynamic. It's not object oriented in the way that public inheritance is. So here's an example we're going to make heavy use of. You might want to write this into your own compiler and play around with it. Like I recommend it, because it's gives you easy enough intuitive example and yet it's important enough that in the real world, it's actually part of the standard library. What I'm just saying is class duo here is actually typically called a pair. And, in modern C++ 11 gets generalized, so it's called a tuple. So you might want to keep that in mind and, as you migrate to C++ 11. But we're going to have our own form of it. We're going to call it duo so it doesn't conflict with a pair in the C++ world. And a pair is going to have a first and second element. And, in this case it's double. If we were to generalize this, everybody should be used to a generalizeation, that would involve a template. And then, this would be T(the meta-type). These things would be T. So if I were to do this in the real world, I would undoubtedly be doing this as a template, just keep that in mind. We see a constructor, first and second, we see some accessor, acc, accessor functions where we can get first and get second, we see some mutator functions where we can set those. And notice what is new is, we have, instead of calling this private, you can call this protected. And protected gives access, for inheritance. So things that are protected are still in the family. So within the family, it's okay to, to work with them. But otherwise, they're seen as private. So if somebody is not in the inheritance hierarchy, they don't see it(protected) any more than private. So you can think of it as private. So when you start using a lot of inheritance, you probably are architecturally going to change how you write your code. You're going to probably turn what used to be private into protected. And now we're going to inherit. So a point is going to be a form of duo. A point is just a duo, but now we're thinking of, not just as a random pair of doubles. But it's more like something on the X Y axis, so here's our duo now. And since it's now representing a point in X Y, we can have a method such as length, square root of the first of the pair times the square of the second of the pair. And duo is a type of point. excuse me, said it wrong. Gotta be careful. Point is a duo. But. A duo is not necessarily a point. So there is this kind of typing relationship. And then all of the members are inherited. Including the constructors. So here's a point, "q". We've set it to be the point (3.0,4.0) A point is a duo but duos are not points. I give it as a Socrates quote, because it's a takeoff on, Plato was a man, all men are mortal, Plato is mortal. But an ape is not a man. maybe or maybe not is an ape mortal? So here we have a calculation and we see that we can do this calculation of length which we couldn't do on duo. There is no length for duo. So the fact is that that has to be a point. That's a point computation. But everything else, the representation issues are all embedded and the code we've grabbed are inherited from duo. What did that program print? This is a little quiz for you so take a second. We had q.set_first() at 3.0, q.set_second() at 4.0. We're going to print out get_first(), get_second(), and then length(). Then what will they be? So, if our set values were three and four, the square root of three squared plus four squared, that's nine plus 16 is 25. Square root of 25 is five. Just remember Pythagoras and you get that right.
