Search code examples
kotlinmodifier

What is the difference between sealed and internal in Kotlin?

What is the difference between sealed and internal in Kotlin? I have read Kotlin's documentation on sealed classes and visibility modifiers; however, it is still not clear to me when to use sealed vs. internal. Maybe someone could provide real-world code samples?

Sealed classes | Kotlin & Visibility modifiers | Kotlin resources.

Solution

  • sealed class will be visible in all modules, but extendable only in the same module. This means if you have this:

    sealed class MyClass {} then you can do this in the same module:

    class MyExtensionClass: MyClass() {}

    But you can't do the same thing in another module. But you can still use both MyClass and MyExtensionClass in another module. For example you can do this in another module:

    val x: MyClass = MyExtensionClass()

    You can't instantiate a sealed class directly neither in the same or another module. This means you can't do this nowhere:

    val x = MyClass()

    So sealed class is basically an abstract class which can only be implemented in the same module.

    internal class can be used and extended in the same module just like a sealed class, but you can do neither in another module. So you can't even use or instantiate it in another module. Also you can directly instantiate an internal class as long as you are doing it in the same module.

    So: Use sealed to better control extending something. For example you create a library and you want a class from this library to be used but not extended. Use internal if you wan't your class to be invisible to other modules (you create a library, but certain class in this library shouldn't even be directly compile time usable by libraries users)

    A good use case for sealed class:

    You build a library and have some abstract class or interface which has multiple different implementations, but you want to make sure the libraries user doesn't add its own implementations (you wan't to be in control of implementation details).

    A good use case for internal class:

    You have some interface and a factory that creates implementations, but you don't want the implementing class to be compile-time visible to libraries users. They just use the factory and don't need to worry about the implementation. They might build their own implementation though and therefor not use the factory you provided and this is OK.