Why isn't Balloon open?

[nikclayton]

Why isn't Balloon an open class?

This question is prompted by an experiment I'm doing. I anticipate having many balloons in the app, and using the "Persistence" feature to only show each one once.

For that to work I need to give each balloon its own preference name.

Having to create and manage each preference name feels like very tedious work, so I thought I should be able to:

1. Create a Balloon subclass for my app that sets various defaults, and overrides preferenceName to return this::class.java.canonicalname. This ensures that each subclass of that gets a sensible preference name.
2. Create a singleton object for each balloon that inherits from the app subclass, sets the text.

Something like this:

package my.app

// actual package: com.skydoves.balloon
open class Balloon {
    open val preferenceName: String? = null
    
    // more code
}

// actual package: my.app
open class AppBalloon(val text: String) : Balloon() {
    override val preferenceName = this::class.java.canonicalName
    
}

object FooBalloon : AppBalloon("hello")

object BarBalloon : AppBalloon("world")

fun main() {
    val foo = FooBalloon
    val bar = BarBalloon
    
    println("foo: ${foo.text}, ${foo.preferenceName}") // "foo: hello, my.app.FooBalloon"
    println("bar: ${bar.text}, ${bar.preferenceName}") // "bar: world, my.app.BarBalloon"
}

This fails at the first hurdle, because Balloon is final, and can't be subclassed from. It also doesn't implement an interface, so I can't implement that interface in my AppBalloon, and delegate to an underlying implementation either.

[JohannesPtaszyk]

Because modern and clean code should always favor composition over inheritance.
Inheritance as a design-pattern especially on libraries, can make changing things unnecessarily hard in the future.
Inheritance limits reusability, makes coupling stronger and in generally makes the thing less flexible.

I would suggest looking into different creation patterns.
For example the factory pattern could be helpful for you, which then internally sets up everything reusable.

[faraz152]

As the previous commenter noted, final is intentional — but the goal you describe (unique preference names per balloon type, without boilerplate) is fully achievable with a factory function:

// A factory that auto-generates a preference name from the call-site class
fun balloonFor(owner: Any, context: Context, block: Balloon.Builder.() -> Unit): Balloon {
    return Balloon.Builder(context)
        .setPreferenceName(owner::class.java.canonicalName)
        .apply(block)
        .build()
}

Usage — as clean as subclassing:

object FooBalloon {
    fun build(context: Context) = balloonFor(this, context) {
        setText("Hello from Foo")
        setTextSize(14f)
        setWidthRatio(0.6f)
    }
}

object BarBalloon {
    fun build(context: Context) = balloonFor(this, context) {
        setText("Hello from Bar")
        setBackgroundColorResource(R.color.bar_color)
    }
}

Each object gets my.app.FooBalloon and my.app.BarBalloon as their preference name automatically — exactly the behaviour you wanted from subclassing, without needing open.

In Compose, the same pattern works with rememberBalloonBuilder:

@Composable
fun rememberFooBalloon(): BalloonWindow {
    return rememberBalloonBuilder {
        setPreferenceName("my.app.FooBalloon") // or a const
        setText("Hello from Foo")
    }
}

The final constraint on Balloon is specifically to protect the internal state machine and window lifecycle — bypassing it via inheritance would risk crashes on dismiss/show sequencing.