This will look like something as described below :
Car class:
public class Car {
String model;
String company;
}
Audi class:
public class Audi extends Car {
String looks;
}
Bmw class:
public class Bmw extends Car{
String speed;
}
Mercedes class:
public class Mercedes extends Car{
String carMercedesFeature;
}
Let’s also have a class called M3 (a sports model of BMW) which will obviously inherit all the properties of BMW.
M3 class:
public class M3 extends Bmw{
int speedLimit;
}
Now, this all works well for now and all the classes work exactly as intended as they all have the properties of the Car class. Now, let’s think upon a situation as below:
Intriguing Question:
-> what if there is a class called airplane which extends our Car class? This is not what we want as airplanes can’t have any properties of cars. We need to somehow make sure that no other class extends our car class which is not intended to. But, the question is, how will we ensure that?
The answer is sealed class in Java!
Sealed classes in Java |
What is a sealed class or interface in Java?
A sealed class in Java is a simple class with an option to specify which other classes can extend it. We can easily define the classes which are permitted to use a class as its parent class. Let’s have an example to understand this.
Continuing our previous example, we want some authorization on which classes can use our Car class right?
Let’s make Car class a sealed class then. The syntax is very simple as shown below:
public sealed class Car permits Audi, Bmw, Mercedes{
String model;
String company;
}
As seen above, we add a keyword ‘sealed’ before our class keyword and add a ‘permits’ keyword, and add the name of classes that we want to permit to extend our Car class. Yup! It’s that simple.
Now, any other class which wants to extend our Car class, like the Airplane class, which is not on the permit list of the class will not be able to extend it.
There is also one other way to declare the permitted classes. If all the other classes which are to be kept in the permit list are present in the same file, we can omit the permits keyword. This is shown below:
package com.mycars;
public sealed class Car{
String model;
String company;
}
class Audi extends Car {
String looks;
}
class Bmw extends Car{
String speed;
}
class Mercedes extends Car{
String carMercedesFeature;
}
But did you guys observe anything in the above classes written? Think for 2 minutes on these questions:
Intriguing Questions:
-> The class Audi is final. What is that for?
-> We also had a class ‘M3’ which extends BMW. Is that allowed? As BMW extends a sealed class Car’
-> the class Mercedes has a keyword non-sealed before it. What is that for?
No worries friends. Let’s answer this question together.
Important points for sealed class:
- For all the subclasses (Mercedes, Audi, BMW), they must directly extend our car class.
- For our sealed class Car, classes Mercedes, Audi, and Bow must be accessible for compilation else java won’t compile it.
- The subclasses that have extended the sealed class must have one of the three modifiers before it. 1) sealed, 2) non-sealed, and 3) final
To explain this point further. Let’s take it one by one. Our subclass Audi has a modifier ‘final’ before it. That means, no other class can/will extend the Audi class.
For our second subclass BMW , it has a modifier sealed against it, which means only other classes permitted by BMW will be able to extend it.
For our third subclass Mercedes, it has a modifier non-sealed, which means any other class can extend it without any restrictions.
Also, all classes must be in the same package or the same module to work.
But, does this make you guys think of something? Does it conflict with the encapsulation paradigm of java?
Conflict with Encapsulation:
Object-oriented modeling has traditionally encouraged developers to hide an abstract type's implementation. Why, therefore, does this new Java feature defy this rule?
Encapsulation can be overlooked when developers are modeling a well-understood and stable domain since consumers will not benefit from the usage of encapsulation in this scenario. In the worst-case situation, it might make it difficult for customers to operate with a basic domain.
This isn't to say that encapsulation is a bad idea. It simply implies that developers are aware of the implications at a higher and more complicated level of programming. So they can decide to move a little further out of line to grab some.
So, guys, we have sealed our knowledge for sealed classes in Java today.
Hope to seal much more in the upcoming articles :-)
Other Core Java articles you may like
- How to use var for local variable in Java?
- How to use Text Block in Java with example
- How to use Records in Java?
- How to use CompletableFuture in Java?
- How to use thread pool in Java?
No comments:
Post a Comment