sealed class at interface sa Kotlin — ano ito, syntax at paggamit

Ano ang sealed class at sealed interface?

sealed class ay isang abstract class na may limitasyon: lahat ng direktang subclass nito ay dapat ideklara sa parehong file ng sealed class. Ang limitasyong ito ay ginagawang sarado (sealed) ang hierarchy — walang code sa labas ng file ang makakapagdagdag ng bagong subclass.

sealed interface, idinagdag sa Kotlin 1.5, ay nagbibigay ng parehong garantiya ngunit may flexibility ng interface: ang sealed interface ay maaaring ipatupad ng maraming klase, object o iba pang interface sa isang file. Hindi tulad ng sealed class, ang sealed interface ay walang limitasyon sa single inheritance — ang isang klase ay maaaring magpatupad ng maraming sealed interface nang sabay.

Ayon sa Kotlin Evolution and Roadmap (2026), ang sealed interface ay idinagdag sa kahilingan ng komunidad para sa mas flexible na pagmomodelo. Ang pangunahing motibasyon ay ang kakayahang pagsamahin ang mga independiyenteng hierarchy ng uri nang walang multiple class inheritance.

Syntax ng sealed class

Ang deklarasyon ng sealed class ay nagsisimula sa modifier na sealed bago ang class. Ang mga subclass ay idinedeklara sa parehong file.

sealed class NetworkResult {
    data class Success(val data: String) : NetworkResult()
    data class Error(val message: String) : NetworkResult()
    object Loading : NetworkResult()
}

Bawat subclass ng sealed class ay maaaring magkaroon ng sariling mga property at method. Ang Loading ay isang singleton (object), ang Success at Error ay data class na may mga parameter. Alam ng compiler ang lahat ng tatlong variant at sinusuri ang kanilang pagkakumpleto kapag ginagamit sa when.

Nested sealed class

Ang sealed class ay maaaring nested, na lumilikha ng multi-level hierarchy para sa kumplikadong modelo ng data nang walang pagkawala ng type safety.

sealed class UiState {
    object Idle : UiState()
    object Loading : UiState()
    data class Content(val items: List<Item>) : UiState()
    data class Error(val exception: Throwable) : UiState()
}

Syntax ng sealed interface (Kotlin 1.5+)

Ang sealed interface ay idinedeklara katulad ng sealed class, ngunit pinapayagan ang pagpapatupad ng maraming sealed interface sa isang klase.

sealed interface Action
sealed interface Loggable

data class Navigate(val route: String) : Action, Loggable
data class ShowToast(val text: String) : Action
object GoBack : Action, Loggable

Ang klase na Navigate ay nagpapatupad ng dalawang sealed interface nang sabay — Action at Loggable. Para sa sealed class ito ay imposible dahil sa limitasyon ng single inheritance. Ang sealed interface ay nagbibigay ng flexibility ng pagsasama ng mga independiyenteng hierarchy.

Kailan pumili ng sealed interface sa halip na sealed class

Ang sealed interface ay mas gusto kapag ang hierarchy ay hindi nangangailangan ng shared state o constructor. Ayon sa JetBrains Kotlin Guidelines (2026), ang sealed interface ay dapat gamitin bilang default para sa lahat ng bagong hierarchy kung saan hindi kailangan ang shared constructor, na ginagawang mas flexible ang code para sa mga pagpapalawak sa hinaharap.

Kumpletong pagproseso sa when

Ang pangunahing bentahe ng sealed types ay ang kumpletong (exhaustive) pagproseso sa when expression. Sinusuri ng compiler na ang lahat ng posibleng subclass ay isinasaalang-alang.

fun handleResult(result: NetworkResult): String = when (result) {
    is NetworkResult.Success -> "Data: ${result.data}"
    is NetworkResult.Error -> "Error: ${result.message}"
    is NetworkResult.Loading -> "Loading..."
    // else ay hindi kinakailangan — alam ng compiler na ang lahat ng variant ay sakop
}

Kung ang developer ay magdagdag ng bagong subclass sa sealed hierarchy ngunit makalimutang iproseso ito sa when — ang compiler ay magbibigay ng error. Ito ay kaligtasan sa antas ng uri, na hindi available kapag gumagamit ng bukas na hierarchy na may else branch.

Ayon sa Google Android Developers (2026), ang sealed class ay ang inirerekomendang paraan ng pagmomodelo ng UI state sa Jetpack Compose. Ang kumpletong pagsusuri ng when ay pumipigil sa mga sitwasyon kung saan hindi naproseso ng developer ang lahat ng posibleng variant ng display ng screen.

Paghahambing ng sealed class sa enum class

Ang enum class at sealed class ay madalas napagkakamalan, ngunit may magkaibang layunin at kakayahan.

Ang pagpili sa pagitan ng sealed class at enum class ay depende sa gawain. Kung ang mga variant ay hindi nagdadala ng karagdagang data — gumamit ng enum. Kung ang bawat variant ay naglalaman ng natatanging field — gumamit ng sealed class o sealed interface.

Praktikal na sitwasyon ng paggamit

Ang sealed types ay ginagamit sa mga proyekto ng Kotlin para sa isang serye ng mga karaniwang sitwasyon na nangangailangan ng pagmomodelo na may type safety.

UI state sa Jetpack Compose

Bawat Compose screen ay maaaring magkaroon ng sealed class UiState na naglalarawan ng lahat ng posibleng estado: Idle, Loading, Content(data), Error(exception). Ginagarantiyahan ng when expression na ang lahat ng estado ay naproseso.

Resulta ng network request

Ang NetworkResult na may variant na Success, Error, Loading — karaniwang pattern sa mga proyekto ng Kotlin na may Retrofit at Ktor. Tinitiyak ng sealed class ang ligtas na pagproseso ng bawat resulta ng request.

Navigation sa multi-module na proyekto

Ang sealed interface para sa navigation route ay nagpapahintulot sa mga module na ideklara ang kanilang sariling mga route habang nananatili sa loob ng isang hierarchy. Tinatanggal nito ang mga error na may hindi kilalang route sa yugto ng compilation.

Ayon sa KotlinConf (2025), ang sealed class at sealed interface ay pundasyon ng type-safe na disenyo sa modernong Kotlin application. Ang mga ito ay pinagsama sa data class para sa pagmomodelo ng kumplikadong domain structure nang walang pagkawala ng kaligtasan sa yugto ng compilation.