Odpowiedź.

Sealed interfejsy to stosunkowo nowa funkcjonalność w Kotlinie (od wersji 1.5), przeznaczona do ograniczenia zestawu implementacji interfejsu w ramach jednego pliku. Początkowo w Kotlinie istniały sealed klasy, które zapewniały ścisłą kontrolę nad hierarchią dziedziczenia, ułatwiając wyczerpującą obróbkę (np. w wyrażeniach when).

Problem polegał na tym, że czasami architektura wymagała nie klasy bazowej, ale interfejsu z tym samym ograniczeniem co do liczby implementacji. Przed pojawieniem się sealed interfejsów jedynym sposobem, aby zamknąć się w ograniczeniach kompilatora, było użycie sealed class, co nie zawsze dobrze pasowało do modelu obszaru problemowego, szczególnie w przypadku potrzeby wielokrotnego dziedziczenia lub dekompozycji zachowań na interfejsy.

Rozwiązanie: Sealed interfejsy pozwalają na zdefiniowanie interfejsu, którego wszystkie implementacje muszą być zadeklarowane w obrębie jednego pliku. Zwiększa to bezpieczeństwo kodu i ułatwia kontrolę oraz nawigację w hierarchii stanów lub zdarzeń.

Przykład kodu:

sealed interface NetworkState

class Success(val data: String) : NetworkState
class Error(val code: Int) : NetworkState
object Loading : NetworkState

Kluczowe cechy:

sealed interfejsy mogą być implementowane tylko wewnątrz tego samego pliku;
sealed interfejsy nie przechowują stanu, ale ich implementacje mogą być klasami z stanem lub obiektami;
wyczerpująca obróbka wyrażeń when dla sealed interfejsu.

Pytania z pułapką.

Czy można zaimplementować sealed interfejs poza plikiem, w którym jest zadeklarowany?

Nie. Podobnie jak sealed klasy, sealed interfejsy mogą być implementowane tylko w tym samym pliku, w którym zostały zadeklarowane. Próba zaimplementowania takiego interfejsu poza plikiem spowoduje błąd kompilacji.

Czy sealed interfejs może dziedziczyć po klasie?

Nie, interfejsy mogą dziedziczyć tylko od innych interfejsów. Ale sealed interfejs może dziedziczyć od innego (sealed) interfejsu.

Czy sealed interfejs wspiera wielokrotną implementację?

Tak, klasa w tym samym pliku może implementować wiele sealed interfejsów lub nawet dziedziczyć zarówno sealed interfejs, jak i sealed class jednocześnie, jeśli jest to dozwolone przez zasady języka.

Typowe błędy i antywzorce

Implementacja sealed interfejsu poza plikiem z jego deklaracją (kompilator nie pozwoli).
Nadużywanie sealed interfejsów dla zwiększonej surowości — może prowadzić do nadmiernej złożoności architektury.
Próba bezpośredniego tworzenia instancji sealed interfejsu — niemożliwe: tylko konkretne implementacje/obiektu.

Przykład z życia

Negatywny przypadek

W systemie przetwarzania zdarzeń sieciowych programista mieszana używa zwykłych interfejsów i sealed klas, w rezultacie powstaje „brudna” hierarchia i duplikacja kodu. Wyrażenia when są zmuszone do zawierania gałęzi else.

Zalety:

Szybko wdrażana architektura
Elastyczność implementacji

Wady:

Nie kontrolowane rozszerzenie hierarchii
Wyrażenia when nie są kontrolowane przez kompilator w zakresie pełności pokrycia

Pozytywny przypadek

W tej samej aplikacji przechodzą na sealed interfejs NetworkEvent, umieszczając wszystkie implementacje w jednym pliku. Teraz wyrażenia when dla NetworkEvent wymagają obsługi wszystkich przypadków. Kod staje się bardziej czytelny, łatwiejszy w utrzymaniu i bezpieczniejszy.