Transcript from the "Abstraction" Lesson
>> So we talked about the core principles of object oriented programming, we had encapsulation, we had inheritance, we have polymorphism. The fourth and final core principle of object oriented programming is abstraction. So abstraction is defined as something that exists in theory, but it does not have a concrete existence.
[00:00:28] I see you all like, what? [LAUGH] Let me give you an example. So, shape is something that is abstract, right? It exists in theory, but it doesn't have a concrete. There's types of shapes and those are concrete, but shape as a concept on its own is abstract, right?
[00:00:56] And in order to declare a class as abstract, we use the abstract keyword right before the word class. This is a non-access modifier that can be used on classes, or it could even be used on methods, okay? Why would you do something like this? It's when you wanted to find a template of a class or a template of a method, but you don't intend for it to be used as is, you want someone else to implement that, right?
[00:01:37] If we were to think about, any abstract thing like shape, or whatever, it's not designed to be instantiated. I don't want you to create a new shape instance, right? It might be a type, but not an instance because what behaviors can it really have, l how can you define that?
[00:02:03] You only could define it once you know the type of shape you're actually working with. So abstract classes, they're designed to be extended and you're pushing the burden of implementation onto the child, the subclass. So again, shape is an abstract concept. It can perhaps specify some general behaviors that a shape would have.
[00:02:33] But it's too abstract of a concept to actually define what the behavior would be. For example, if I had this shape class, then it can't be instantiated. Its purpose is to serve as a superclass that more specific subclasses can extend from. Now an abstract method is a method that has no body.
[00:03:04] And we will put that non excess modifier in front of the return type. For an abstract method, only the signature of the method is defined. Again, it's not defined to be run as is, is designed to be overwritten by a subclass. This is a great example because I have the shape class and I have calculate area.
[00:03:35] I cannot think of an implementation to put inside of this method. In shape, how do you calculate the area of a shape? Well, it depends on the shape, right? That's exactly what you would say. So that's what we mean, you can say, look, if you have a shape, you should provide a method to calculate the area.
[00:03:55] I don't know what that implementation is going to be, but you need to have one, okay? So, we are going to create an abstract shape class and then, I'm gonna create a new rectangle class. I don't wanna do too much with that other rectangle we have. So we'll create a new rectangle class that will inherit from shape.
[00:04:29] So back to our IDE, we want to make a new package called abstraction. In abstraction, we'll create a new class called shape. And to make this class abstract, what do we do?
>> Abstract after public.
>> Yes, after public we would write abstract. So that's what we do.
[00:05:17] This class is now abstract. Let's create the abstract method. So we say abstract, double calculate area. Now you don't have to only have abstract methods in an abstract class, you can have some methods that have a body. So let's just add one of those for fun, we'll say public void print.
[00:05:51] And we'll print out that I am a shape. All right, let's make the rectangle class. Now, this is a great example that I haven't explicitly called out, but we're making a new rectangle class. We had another rectangle class that was in objects. It's okay to have classes with the same name as long as they're not in the same package.
[00:06:42] And of course there's no relation between them. All right, so in the rectangle class we're going to extend from shape. Write our weight, as soon as we do this inheritance, we get an error. Because if you're going to inherit from an abstract class, you must implement the abstract methods that you have inherited, or you can define yourself as an abstract class as well.
[00:07:17] So you have two options. Implement the stuff that needs to be implemented or pass the buck yet again to your kid. All right, so inside of the rectangle class, let's go ahead and implement the abstract method that we inherited. You could type this out manually, but of course, IntelliJ offers us some nice ways to handle this.
[00:07:47] So, if I hover over the error, they give me some options. I can just click this Implement methods. It shows me which methods are abstract and it added it there. I do need to change the body here though. All right, so we'll change our calculate area to length × width which we haven't defined just yet and rectangle, but we will, okay?
[00:08:24] So in our rectangle class, let's go ahead, we handled the part about over overriding the abstract methods that we inherited. Now we can take care of our own business and rectangles. So let's make a couple of fields for length and for width. Let's just leave that for now, we'll add more if we need to.
[00:09:06] I guess we need to add a constructor to set this stuff up though, right? Otherwise we can't set the fields so let's just do that much. What's this type of constructor call?
>> All arcs?
>> Yes, all arcs. I'm putting all of the fields in the parameter list so we can say, we don't have a setter?
[00:09:32] [LAUGH], I might as well go ahead and generate my getters and setters. I was trying to be lazy, but. Generate, getter and setters for both, yes. All right, and let's set the length. And set the width. Okay. All right, now let's make a test class that'll test the abstract stuff.
[00:10:10] So in abstraction, we'll make a class that we'll call ShapeTester. Make your main method. Okay, we're going to define this as shape, which is the superclass, which is abstract, right? Shape, rectangle, we cannot say new shape, why not?
>> Is abstract so you cannot instantiate an abstract class, not possible.
[00:10:53] So we would have to use one of its subclasses. When you say new rectangle, make sure you're using the one that's in this package and not the object one. And let's just give it a couple of numbers. Okay, and I can say rectangle.print, which comes from the shape class.
[00:11:22] So that's normal inheritance, right? By do that, let's just test what that does. It says I am a shape perfect that's what we got from the shape class here. And then let's test out the area, right? So let's say rectangle.calculatearea. And of course, it's going to run the one from the rectangle class that we have some implementation for.
[00:12:01] So that should be 35, yep. Yes.
>> So an abstract class probably can't be final then?
>> Can't be final? Okay, that's a great question, right? So, abstract, final, that doesn't make sense, right? Because that's exactly what it says, a legal combination. I love that question, I love the way that they're thinking.
[00:12:30] The purpose of the abstract class is to be a template that will be implemented by subclasses. So to make yourself final means no one can be a subclass, no one can inherit from you, and that doesn't make sense. Good question.
>> You back to the shape duster?
>> That's an interesting question though. So you can't extend an interface?
>> A final class?
>> No, an abstract class?
>> Yeah, you can, we did here.
>> So rectangle, extended shape.
>> Not extend or extend, right?
>> So a final class can't be extended. An abstract class is meant to be extended.
[00:13:13] So an abstract class can't be final.
>> Probably sealed as well, right?
>> What can't be?
>> Couldn't be sealed.
>> Abstract class.
>> Can an abstract class be sealed? Interesting, so there might be, that might be possible I don't see why not. All sealed class, and then we have to say wait what?
>> Must be final seal, yeah. So then this would have to, let's just say non-sealed here, yeah. So that's fine, you can have an abstract sealed class. That was fun. I've not done that before.
>> Wouldn't that be kind of unhelpful because you're essentially creating a class where you can't do anything with it, but you can't implement it either because of the sealed.
>> You can do stuff with it, right? You can do whatever you want as long as you're on the list.
>> I see what you're saying, yeah.
>> Yeah, so, having a sealed abstract class just limits who is able to implement, those abstract methods,
>> Like the bouncers letting you into the club.
>> Yes, that's right, we're on the list [LAUGH]. All right, so key points to remember about abstraction or abstract classes and methods are templates, they're meant to be implemented by their subclasses. The classes in the methods are declared abstract, by using the abstract reserved words.
[00:15:10] If a subclass inherits from an abstract class, it must, it's required to implement the abstract methods of that class. Or it has to declare itself as abstract. I didn't show you that. Let me show you that. I told you that, but I didn't show you that. So, in rectangle, so okay, shape is abstract.
[00:15:36] Rectangle inherits from shape. Let's say that they're, look, I don't want to implement the calculate area method. Of course, this gives you an error. So rectangle could say, look, I'm abstract too. And then they're off the hook. And the reason why you might wanna do this, so we just had one abstract method and shape, there could be 20 abstract methods and shape.
[00:16:07] And rectangle can say I only need to implement five of those the rest of them are not really applicable to me. So then rectangle would have to. They could go ahead and override those five abstract but they would have to declare themselves as abstract as well cuz they have 15 abstract methods that they have inherited.
[00:16:33] Again, abstract classes cannot be instantiated. They are only to be used as a superclass.
>> Once in your example, make the rectangle class abstract, that child would have to implement not only the five abstract methods from rectangle, but also the 15 that rectangle did not.
>> Is that, maybe, why you make a default method, if you change the parent, you wouldn't have to require all the children to implement.
>> Yes, but it's not an abstraction, it'll be in the next topic we talk about but yes that's the reason.