Object Oriented Programming with Java, Abstract Classes. So, we're going to look to see what is the difference between concrete and abstract classes and how are they used. And as part of this discussion, we're going to have a conversation about something called casting, at least a formal one. We've already used that term and had a couple of examples, but now we're going to deal with it more formally. So what is an abstract class? An abstract class is a class that may not be instantiated. You cannot say new on it. You can however, create references of it. So, the abstract class can be used to describe, what you can say via the reference. But the class itself is perhaps partial, and so we cannot actually create an instance from it. Now an abstract class is a class, so we can include attributes, methods, and abstract methods. Abstract methods have no code, they're basically placeholders with a signature. So when do you use them? You don't use them all the time. In generally, in order to use them you should be meeting a certain criteria for your use case. You have attributes and method implementations that you want to share with a range of subclasses. But it should not be possible to create instances of the abstract class itself. Especially, because there may be methods that you can't describe the implementation of, that must be defined by the subclass. In this sense, abstract classes are more in the realm of being implementation details than design. You have perhaps multiple classes and you realize that they have some things in common that you want to factor up into a common parent. But the common parent is not complete enough to be instantiable. So these abstract classes are generally partial classes with those abstract methods as placeholders for the missing parts. They're often use to build out framework. The parent class may have common behavior, whereas the specific details that must be defined by a child class are now able to be forcibly delegated to do it. When I say forcibly, it's because the child class itself will have a syntax error if it is not abstract itself or implement the missing parts. One quick little example very brief. Consider a database transaction class, where the parent class database transaction is providing some overall management. But the individual child classes that extend this, provide statement construction. So DBTransaction is marked as abstract. And getStatment, which would return a SQL statement, is abstract. So given a bunch of DBTransaction references, I can now call the perform() method. And that can do all the common stuff about setting up to be able to do a transaction, making sure the driver is loaded, getting a connection, doing whatever it takes. And then, do whatever the getStatement says, so go get a statement and go ahead and do it. And then, let's consider if we're going to commit or rollback. So preparing for the transaction and the post processing is all done here, but the required getting of a statement was done by the specific child classes. So here's another example. This will lead into our little demo that we'll do. This is using car, and as you can see car has been marked as abstract. Now, sometimes it's hard to figure out what the examples should be. And I don't particularly like this example. So we're going to do a slightly different variation on this in our own live demo, which would be our next lesson. What's happened here is, speed has been made protected and setSpeed() has been made abstract. It is not generally a good idea to have protected attributes. Remember, that means it can be visible directly to all of our subclasses. I don't even like using attributes directly in the class itself I prefer to use Setters and Getters. So, definitely not a fan of protected attributes. Speed should still be private and setSpeed is perhaps not the best choice for our example. But again, just for the moment, we're going to go with it, so we can see the mechanics of an abstract method. So the mechanics are, it is marked abstract and has no body, just a semi colon. Now, SportsCar extends Car and does not say itself that it's abstract. Therefore, it must implement setSpeed and here's the implementation of setSpeed. And because speed itself was marked as protected, this works in our next lesson and look at a slightly different variation on our car example
