Hi everyone.
Welcome back.
In this lecture we will learn about the most interesting concept which is sealed classes or interfaces.
I will start with some theory first and then we'll get to the coding part.
This concept got released and it was generally available from Java 17.
So if you are using Java 17 already, then you can leverage this concept and then start using it from
now on.
The basic idea is to allow inheritance by permission.
So that's this concept is to restrict the inheritance.
But you will still be allowed to apply inheritance by permission.
Let me explain this using a simple example.
As we all know, Java is very open by default.
What do I mean by that?
Any class can extend other class as long as it is accessible.
In this example we have a vehicle class which is a superclass, and having a truck class and the car
class extend the vehicle class.
Make sense?
But having a dog class extend the car class.
That does not make sense, right?
But technically, from a language perspective, you can still do it.
There is no language constraint that's going to prevent us from doing it and listen until if a developer
recognizes this and catches it before moving this code to production.
But wouldn't it be nice if we have a language feature that can automatically prevent this for you?
This is where sealed classes or interfaces comes into play to prevent this kind of behavior.
Let's look at the same example with the addition of sealed keyword in our class hierarchy.
So in this case we have the vehicle class.
But if we take a look at it we have this sealed keyword added to the definition.
So what this is going to do is that this is going to have another block where or another keyword it's
going to permit only the car and truck.
Right.
So whatever that comes after the permits, those are the only classes which are allowed to extend the
vehicle class.
That's the actual definition of public sealed class vehicle permits car and truck.
And here we have the final keyword added to the subclasses.
And it is to make sure no more inheritance is further allowed on these classes.
But there are other options available which I'll cover in the next lecture.
Let's say in this case, if the dark class tries to extend the vehicle class, the compiler will complain
about dark class being not part of the hierarchy and it is not allowed.
I hope the explanation is clear.
So the fundamental idea is to restrict inheritance from a language perspective, meaning applying the
restriction while defining these classes.
So with this information, let's go ahead and explore the sealed classes in action.
Now let's go back to IntelliJ.
There we go.
So in the IntelliJ we are going to be working on the sealed package that you see over here.
And then let's go ahead and open the vehicle class.
So if you take a look at the vehicle class what we have is that this vehicle class act as a superclass
for the car class, the dark class, and then the truck class.
So actually we are going to be breaking this inheritance here.
You can see right.
The dog is extending the vehicle class.
I just created this class on purpose so that we can actually understand the impact of this one.
I'm explaining this concept using a very simple and naive implementations.
In the future part of the course, there is a dedicated section where we will be building a real time
application using all the concepts that we will be learning as part of this course.
Okay.
So now what I'm going to do, I'm going to go to the vehicle class.
And in here I'm going to add the shield modifier.
So when I add the shield modifier what this is going to do.
So this is going to be giving me a compilation issue.
So the compilation issue says add the missing subclasses to the permit classes.
So I'm going to click on that one.
So in this case what we need to do.
We don't want the dark class to be part of it.
Right.
So we just need the car class and the truck class.
And then it complains about car class being not final and car class being a regular class.
So this is something which we'll look into it on.
What are the different options for now?
What we are going to do is we are going to add the final modifier.
So what this final modifier is going to do, this is going to make this class final.
And then stop allowing any kind of inheritance from here.
So let's go back to the vehicle class and we'll do the same thing for the truck class.
There are different options available which we will talk about in the next lecture as I mentioned.
There we go.
So the compilation issue is gone right.
So now if you go to the dark class this is not going to be allowed.
It says like a dog is not allowed in the sealed hierarchy.
So in this case the compiler catches it, right?
So in this case you go ahead and remove it.
That's the only way to have this code compile.
So with this code in place what we are achieving is that we are achieving the inheritance from the language
itself.
So when you define the class you make sure what are the different classes that can be part of the hierarchy.
And you can achieve this by using the CL modifier and then the pyramids.
Now let's learn about some of the techniques to write test cases to make sure the car and truck is part
of the vehicle hierarchy.
So now what I'm going to do I'm going to create a test case.
So it's going to be the vehicle test.
And then it's going to be under the sealed package in the test folder.
Then what you do click okay.
There you go.
The test case is ready.
I'm going to move this one to the right.
In this case what we will do.
We'll create a test case named let's add the annotation over here.
And then the test case is going to be vehicle test.
It's going to be vehicle.
And what we are going to do is that we are going to create a car.
It's going to be where car is equal to new car, okay.
And then we are going to do the same thing for the truck.
To where.
Truck.
New truck.
Okay.
And then how do we make sure this car is an instance of a vehicle?
Right.
So there is a assert instance of function which we can leverage.
So assert instance of.
So we can provide like a vehicle because we want to make sure car is part of the vehicle hierarchy.
Right.
So we can do this and then pass the instance car.
And we can do the same thing over here.
And this is going to be truck.
So this is how we make sure we have test cases that's going to assert this behavior.
Right.
So we have defined the hierarchy here.
But we need to make sure with a sealed and permit is it really going to work as expected.
So in this case run the test case.
There you go.
The test case passed.
That means the car and truck is part of the vehicle hierarchy.
So this is how you create sealed classes.
And the fundamental concept is to allow inheritance by permission.
So this is a handy feature I have used this in many of my projects.
It's really helpful if you have this kind of hierarchy related code, you should start using the sealed
concept in your project two.
This marks the end of this lecture.
Thank you for watching.