Now let's look at a live example of an abstract class. Here is car, and I have already gone and marked car as abstract. I have added a new method. Previously, we had this issue of max speed being a private static constant of this class, and different types of cars might have different max speeds. We're no longer going to have this private static final, this constant. We're going to have a public abstract method called getMaxSpeed, the individual parts of our hierarchy will have to define for us. Having marked car as abstract and provided public abstract getMaxSpeed and saved it, car itself is happy, it's fine. But if you look over here, you'll notice that both cargo and sports car, the two immediate descendants of car are no longer happy. They're marked as errors. The more interesting thing to note is that neither station wagon or SUV are marked as errors because the two hasn't applied any rule of transit of closure. Let's go first work on sports car. It's telling me it's an error because it must implement the getMaxSpeed methods since that's the abstract, and we can either make sports car itself abstract or implement that method. We're going to go ahead and implement that method. Right-click "Source", "Override/Implement Methods", and the one that we need is getMaxSpeed, which has been preselected for us. Click "Okay". We now have a getMaxSpeed and we'll adjust the max speed of our sports car to 350. Now sports car is okay and has a max speed of 350. Cargo is not fine. We would have two choices here. We could implement it here, making it available to station wagon and SUV, and we probably could. But just to show the example of propagating the abstract method further down, I'm not going to implement it here. I'm going to check the other choice, making cargo itself for abstract. It doesn't make sense to say new cargo, so now cargo itself is abstract. I could implement getMaxSpeed in both station wagon and SUV, and I implied that I would, but I actually don't have to do that here because even though I've marked cargo as abstract and I don't want cargo itself to be instantiated, I don't need to not to implement this thing and leave it go to the child classes. I'm going to go and override and implement the method anyway. I'm going to go implement getMaxSpeed, and I'll go ahead and give it a default value here. For all cargo carriers, their max speed will be 100. Having done that, station wagon and SUV or happy again. They didn't have to implement it, but that still doesn't mean I can create a cargo. Let's look one last time at car.java, there was one other change I had to make. Here is a reference to max speed, and since we no longer have max speed, that has been changed properly to getMaxSpeed. We'll get the max speed based on whichever type of vehicle it is. Now car app has a problem, let's go take a look at that. Here is the example of what it means to be abstract. You can't just create a car, cars are abstract now. We're going to make car 54 a sports car, which is a rather amusing upgrade to the original vehicle. That's a sports car. But you see, and I'll just reuse that reference for a moment, we cannot say car 54 equals new car because car is abstract, so you can't instantiate that, nor, can we say make it a new cargo. First, let's organize imports as we have it. Now we have cargo and we still can't do it because it's abstract. I'm going to go ahead and remove it. If you look carefully up here related to cargo, you're going to see it disappear because it's no longer referenced and I redid the organize imports. Let's go ahead and run this. Works perfectly, but we've now demonstrated the use of an abstract class with an abstract method, and I've even demonstrated in the case of cargo, that it can even be complete and we still don't want to be able to instantiate it. Marking it abstract will mean that only its subclasses can be instantiated.
