Transcript from the "Overriding Parameters" Lesson
>> Let's talk about overriding inherited methods. So methods that we have inherited from a superclass. What if we don't want that implementation and we wanna override it to do something different. That is allowed, all right? So we are going to create a square class that inherits from rectangle and we're going to override its calculate parameter method, right?
[00:00:33] Now, if we go to our IDE, I'm gonna close these out. And remember. We already created a rectangle. Where did we create that? We created a rectangle in the objects. So just for fun, let's go ahead and inherit from that class, okay? So we'll make a new Java class we'll call this one square.
[00:01:10] And in order to inherit, what must we write.
>> Extends, and what else?
>> And the parent class, rectangle.
>> Rectangle, all right? And so, now, this square class is inherited from rectangle. Rectangle was not in this package, so, we did need to import it. When we inherited from the rectangle class, we get all of the rectangles goodies for free, including the calculate parameter method.
[00:01:45] However, we do want to override that to a specific calculation for square. So in order to override it. We're going to recreate that method, it has to have the exact same signature, of the method you inherited. So, I never try to type it out, cuz I might make a mistake, right?
[00:02:12] And instead I just go ahead and copy, the signature. So we'll just copy this from rectangle and we'll paste it inside of square. And to override this we will simply change the body, okay? So we change it to whatever we want right here. Before we change the body, now I copied this over, right?
[00:02:46] There's another measure you can take just in case you type it out yourself. And it's also just a good practice, convention not required. But you can do an @override above the method. This tells Java and also tells any other programmer that might run across this code that this method you inherited and you're overriding its implementation.
[00:03:14] Now, this is helpful with the compiler because let's say, I just couldn't spell and I did this. And when I was trying to type it out, notice here I now have an error and they're saying you didn't inherit this method what are you talking about, right? And I know I messed something up, all right?
[00:03:34] So that's a really helpful way to catch any mistakes. Okay, inside of the calculate perimeter, we'll change this to return sides × length. All right, and we have a little problem here, right? It's saying it doesn't know sides are length. If we go to rectangle, why might that be?
>> They're private.
>> They are private. So when you inherit from something, the superclass only gives its child class the things that are not private. Private means its scope just to this class. So it's a good practice if you're okay with other classes extending you to make this protected, so that'll still give you that encapsulation, but other classes can utilize these fields.
[00:04:50] All right, and now notice we don't have size or length declared in this class explicitly, but it inherited those fields from its parent rectangle.
>> Does it also imply that it has access to those getters and setters as well?
>> Yes, so those are public, so it definitely has access to these, okay?
[00:05:21] All right, questions on overriding. Yes.
>> Do you only need to change what you're trying to use in a different class to protect it or do you have to change everything to protect it?
>> Only the things that you want inherited. Now, in real life, there may be classes that you want to inherit from, maybe they're from the Java library, and you won't have access to modify those access modifiers like that.
[00:05:58] So, you only can change it if it's within your own code base, right?
>> Any reason not to.
>> The other way you could have done this. So let's say you did not own this class, you have no permission to change this stuff to protect it. But you want to still inherit from it.
[00:06:27] You can simply use the getter and setter methods. So get sides × get length, because that was the purpose of encapsulation, right? Utilize my methods, not my fields. So if we were to say rectangle like we had a new object rectangle.calculate perimeter which method would it run the one in rectangle or the one in square?
>> Cause of the over?
>> Yeah, so you overrode it. So if we had a square object and we said square.calculate perimeter, it'll run the overwritten implementation, okay? So let's go inside of inheritance tester and we are going to check for the overridden method, okay? So we'll say square which is the subclass, right?
[00:07:40] Square = new square. And we'll say square.calculateperimeter. Now we haven't set any of the fields yet, right? So we need to do that. Let's say square.set length. What was it? Side and sorry. Square side × length, okay. So, side was already set to four and rectangle remember hard-coded so we just say the length.
[00:08:17] Let's say 25 oops 25, so that we have a nice, what? 100, okay, rectangle will we get that same number? Possibly, two times the length and two times the width, no, because width is not even set right? Right, okay [LAUGH], so let's run this to make sure that it ran the overriding method.
[00:08:48] I need to print it out, okay, print out this. And boom we got a 100, okay?