j21-sealed-interface - Blog of Vincent VAUBAN

Declaring Sealed Interfaces
with a Carrefour Shops Example 🛍️

Just like sealed classes, sealed interfaces in Java allow you to explicitly control which classes or interfaces are allowed to implement or extend them.
To seal an interface, add the sealed modifier to its declaration. Then, after any extends clause, add the permits clause, which specifies the classes that can implement the sealed interface and the interfaces that can extend the sealed interface.
This is particularly useful when modeling a restricted hierarchy, ensuring a predictable and safe extension path.
🛒 Example Scenario: Carrefour Shops
Let’s say we’re designing a system for managing different Carrefour store types, and we want to define common behaviors shared across them—like calculating their operational complexity or capacity—but we want to limit which specific store types can exist.
We define a sealed interface called CarrefourShop, and explicitly state which implementations are allowed: CityStore, MarketStore, HyperStore, and DriveStore.

👌 Permitted Implementations
Each permitted class implements the CarrefourShop interface, providing a specific behavior:

💡 Key Concepts Illustrated
🟣 sealed interface CarrefourShop restricts implementations to only approved store types.
🟣 All implementations are marked final to prevent further extension.
🟣 The system models various compositions of store types using class composition, mirroring how Carrefour combines store formats for different regions.
This approach keeps your type hierarchy explicit, safe, and easy to maintain—no one can add an arbitrary store type without permission from the sealed interface.

Declaring Sealed Interfaces

Just like sealed classes, sealed interfaces in Java allow you to explicitly control which classes or interfaces are allowed to implement or extend them.

To seal an interface, add the sealed modifier to its declaration. Then, after any extends clause, add the permits clause, which specifies the classes that can implement the sealed interface and the interfaces that can extend the sealed interface.

This is particularly useful when modeling a restricted hierarchy, ensuring a predictable and safe extension path.

🛒 Example Scenario: Carrefour Shops

Let’s say we’re designing a system for managing different Carrefour store types, and we want to define common behaviors shared across them—like calculating their operational complexity or capacity—but we want to limit which specific store types can exist.

We define a sealed interface called CarrefourShop, and explicitly state which implementations are allowed: CityStore, MarketStore, HyperStore, and DriveStore.

👌 Permitted Implementations

Each permitted class implements the CarrefourShop interface, providing a specific behavior:

💡 Key Concepts Illustrated

🟣 sealed interface CarrefourShop restricts implementations to only approved store types.

🟣 All implementations are marked final to prevent further extension.

🟣 The system models various compositions of store types using class composition, mirroring how Carrefour combines store formats for different regions.

This approach keeps your type hierarchy explicit, safe, and easy to maintain—no one can add an arbitrary store type without permission from the sealed interface.