Java Fundamentals

Sealed Classes

Angie Jones

Angie Jones

Java Champion
Java Fundamentals

Check out a free preview of the full Java Fundamentals course

The "Sealed Classes" Lesson is part of the full, Java Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Angie demonstrates restricting inheritance to specific classes using sealed classes. The NonSealed keyword is also briefly discussed in this segment.


Transcript from the "Sealed Classes" Lesson

>> Let's talk about sealed classes still in inheritance. Not only does Java classes have control over which of its methods can be inherited, but they can also restrict inheritance altogether to certain subclasses. And this is a relatively new feature within Java. So classes that restrict inheritance to specific classes are known as sealed classes.

So sealed classes are useful for modeling like a specific domain and controlling the relationship between the classes in that domain. So here we have four classes shape, circle, rectangle and square. We can declare that the only classes that can directly inherit from shape are rectangle and circle. And we could allow square to inherit from rectangle, okay?

So this is how you would define a sealed class, before the word class, you would write this keyword sealed. And then before you open those curly braces, you would use the word permits. So this is the super class. After permits, you would have a comma delimited list of the classes that are permitted to inherit from this class, okay?

If a sealed class lists a subclass in the permits clause, the subclass has to all ready exist, right? And it has to extend this class. Otherwise you're gonna get a compilation error, right? So Rectangle extends Shape, Circle extends Shape, and then Shape has permitted Rectangle and Circle. Now, the children of sealed classes are also required to declare themselves as either sealed, non-sealed or final.

They have to do this, the sealed class controls who can inherit from it. So in our domain, the Rectangle will make a good sealed class as we only want to allow Square to extend it. So in Rectangle here, we said, okay, we're sealed and we extend Shape and we permit Square.

So now you see it's getting a little longer. We're doing a little inheritance, and then we're also saying, who can inherit from us? Non-sealed means that the class is open to be extended by any other class. So we'll declare Circle as non-sealed. And any class that extends Circle is not obligated to declare themselves as sealed, non-sealed or a final, right?

It'll simply be a normal inheritance. So we kind of break the rule by, well, stop the rule there when we make ourselves non-sealed. So none of our children have to deal with this stuff. And then final means that the class cannot have any subclasses, right? So it cannot be inherited from.

So Square would be the last of the descendants in this hierarchy. Questions on sealed? Okay, to recap a sealed class grants inheritance to a specific list of classes. Every permitted subclass must all ready exist, and it must explicitly extend the sealed class. And if it does then it must declare itself as sealed, non-sealed, or final, yes?

>> For sealed classes, because the sealed inheriting class has to all ready exist, so that implied has to be in the same package, just to know about it?
>> No, you would just import it if you were talking about a subclass that was in another package.
>> But like the overall overarching class, like the class that's above it in the hierarchy still has to know about the class underneath it in order for it to, like on the valid permissions list?

>> Yeah, you gotta know it exists.
>> All right.
>> Yeah, you have to know its name and like where it lives, what package it lives in. And again, no one has to declare themselves as a sealed class. It's specifically for things where you don't want everybody inheriting from you.

Maybe you're modeling some specific construct or domain and you're saying this is how the inheritance should go. So an architect might do something like this to control who inherits from who and keep things simple or something like that.
>> So, when do you have to use the non-sealed keyword, it's a keyword, right?

>> Yeah, so you would use the non-sealed keyword when you no longer want, like if you don't want your children to. You no longer have a need to do a permission list, right? So I inherited from a sealed class but I don't wanna be a sealed class, I wanna be open for regular inheritance.

So you would say non-sealed.
>> Okay, so you break that basically?
>> Yeah, you break the-
>> The chain of restriction or whatever.
>> Yeah.
>> Then like, class a is sealed, class b is non-sealed. For class c, would you have to use like non-sealed cure at all?

>> b is non-sealed.
>> b is non-sealed.
>> c inherits from b
>> c inherits from b.
>> c inherits from b, then it's a regular inheritance. You don't have to use sealed, non-sealed, final or anything like that anymore.
>> If you use the final statement, and if you wanted to add another class in there, it would have to be prior to the final statement or could you add another?

>> So if you had a final class and you want to update your own class later, you can do that. Yeah, you can do it. The final part means, anyone who inherits from you or they can inherit from you, no one else can inherit from me, is what that means.

So you can do whatever you want in the class itself. You're not saying this is the final implementation, but you're saying this is the final stop on this inheritance chain, no one else can inherit from me. And if you had like final can be on classes, it could be on methods, or it could be on fields.

So if it was on not the class but on a method, then someone can still inherit from that class. And they also inherit the final method, they just cannot override that method. And if it's the field, they inherit the field but they cannot change it.
>> So if you had a hard-coded constant, that's one of those cases where you'd wanna use the final keyword on that field or that variable?

>> Yeah, all right? Any other, yeah.
>> So sealed is kind of an extension of final, no one can inherit sealed only specific can inherit?
>> Sorta, I don't like to think of it like that though. So I guess so, it's a way to limit access for sure.

So with final you're saying, no one like the descriptor they gave was correct but the terminology is not my favorite. But okay, yes, the final means no one else. If I have a final class, no one else can inherit from this. If I have a sealed class, then only these classes can inherit from this.

So in that regard, yes, but not an extension of final. But a way to limit access, yes.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now