Polymorphism is a Greek word for many faces. But in object oriented programming, and here in Java, it means that more than one class can have the same method name. And particularly for Java signature but different implementations. However, in Java, that requires more than simply having the same name and signature. In Java, it will require inheritance. Because unlike some other languages in Java polymorphism requires in inheritance either through a class or as we will see later through interfaces. So the parent will specify at the least the name and signature of the method. Remember that a signature means we're also recognizing it based on the types and order of parameters. So all descendants of that parent inherit the declaration. Now a class that inherits the method can either implement or re implement the method as necessary in whatever way it wants, including overriding a parent's implementation. So here's an example we have car. Car has speed gasoline engine state, the setters and getters. Over here we have station wagon has cargo capacity current cargo load. A set speed and a set current cargo load. The fact that we see set speed here, notice you don't see get speed here. Is suggesting that the station wagon is in fact going to override set speed. Likewise, the sports car has horsepower and a set speed. So we have two sub classes. Two child classes both of which are inheriting from Car. All of them have a set speed method. Polymorphism is going to mean that we can create Station wagons and sports cars and regard them as if they're all cars. Now we've already done that because we already have station wagon in our demo. But now we're also going to have sports car and we're going to look at this aspect dealing with set speed. So here is our demo. Here is car and this is the code related to set speed. Here's the max speed. I've increased it to 350 to facilitate our demo. Here's the private attribute for speed. So remember that's private. The sub classes cannot set it directly. Here's get speed and here's our set speed, which makes sure you're no faster than the maximum speed. So let's take a look now at Station wagon. Station wagon is unchanged from the code we last saw. But I'm now going to go ahead and show you how to implement set speed here. So first I'm going to right click source, override or implement methods. And the only one I want to talk about right now is set speed. So let's go ahead and generate it. And here's my newly generated set speed. It's a reminder that would show up telling me don't forget to implement this. And here it has already brought in super dot set speed. We'll be revisiting this topic but that's how my set speed here is going to be able to use the parents set speed. Because after all, I do not have direct access to that attribute. So we're going to set here for station wagon the speed based of the current cargo load. And our logic here is simply going to be take the current cargo load divided by 100 and subtract that from new speed and that will be our result. Now the sports car. I have already implemented this for us. Here's our constructors. Here is its set speed. Set the speed to whatever our current speed is times 1.10. Since set speed takes an int, I do have to cast this which will also mean you dropping any fractional number. Now in both cases, you might have noticed this act override. That has no effect whatsoever at runtime. But here in the parser and in our compiler, it will check to make sure that we're actually overriding something from the parent. For example, if I were to think, Let's just make this a float. I'm now getting an error because it's telling me. But since we did say act override, this implementation of mine must actually override something found in the parent. And the parent does not have one that takes a float. Only one that takes an int. This is a safety check and nothing more to make sure that I haven't accidentally introduced a new signature, which should be an overload. An override means the same signature. An overload is the same name with a different signature. So the Add override annotation here is nothing more than a safety check to make sure that I actually am overriding So finally, let's come to our Carapp. Here is the Carapp, and here's the mach5. And let's just go ahead and run this. Car 54, which is a regular car was told to go at 20 miles an hour and it still is. The Mach five is a regular car was told to go do 50 and it is. The station wagon was told to go at 75, notice it's only going at 70, it's subtracted the mileage. We haven't yet made this a sports car. And that was on purpose. Let's just change this now to sports car. The reason I want didn't do that beforehand was to show the effect of what happens when we do make that change. For one thing you'll notice that we are getting an error here because we do not have an import for sports car just car and station wagon. So when that happens source. Organize imports, otherwise known as Ctrl Shift O. Ctrl Shift O is one of the most frequently used key sequences, at least when I'm programming in Eclipse. Because it will go ahead and find the imports it needs and add them. And any extraneous imports, perhaps something I used to use that I don't use anymore will be removed. Here is sports car now. Their error is gone. Let's go ahead and save it. If you look carefully up here at the title bar, there's an asterisk right near to the next to the file name. That's how Eclipse tells us. That it hasn't been saved yet. Watch as I hit control s and the asterisk has gone away. Let's go ahead and run it. Now the Mach 5 is traveling at 275 miles an hour. That is the 10% boost we decided to give a sports car. There you see the impact of having a custom set speed, car just does the regular thing as long as it's less than the max where as station wagons slow down a little, the more load we add. There's dropping one mile per hour for every 100 pounds of cargo, and the sports car is going 10% faster than what you asked it to do. And there's an example of polymorphism for set speed. So, you saw that we are able to invoke set speed. And our list of things was just car, right? We didn't change that. This was still a car array, and the loop variable was still of type car. But since car declares the sets bead method and the others inherit we're fine. Polymorphism exists with inheritance all of them have a common ancestor which is car and therefore that is acceptable. So we're able to treat any subclass of car as a car, station wagons, sports cars, and the others that might come up. But when we invoke set speed, regardless of the type of the reference, which for our case was car, it is the actual implementation that matters. And the way I like to describe this in Java is as follows. Car is that type sports car is the class. Be very specific in our terminology if you use it consistently. It will help you to understand what we declare on the left hand side is our reference type. What we say on the other side of new is our class. Type versus class. They may be the same thing car and car, or they may be different. My class sports car must be compatible with my type, but not identical. And this becomes incredibly useful and powerful in object oriented programming. We will have an upcoming module dedicated just to polymorphism
