Kotlin umożliwia nam pracę z różnymi rodzajami klas. W tym poście zamierzam krótko omówić każdą z nich wraz z modyfikatorami widoczności (Visibility Modifiers).
Język dla klas oraz innych obiektów takich jak: funkcje, konstruktory czy intefejsy dopuszcza cztery modyfikatory. Poniżej przedstawiam tabelkę z wytłumaczeniem.
Zanim pokażę przykład, który nieco może rozjaśnić użycie tych modyfikatorów, trzeba powiedzieć o jeszcze jednej rzeczy.
Aby móc dziedziczyć po danej klasie, musi ona zostać oznaczona jako open lub abstract.
Domyślnie w Kotlin'ie klasy są finalne, a wywodzi się to z Effective Java Item 17. Słowo open jest całkowitym przeciwieństwem Javowego final.
Warto o tym pamiętać, gdyż wiele framework'ów wymaga by klasy były non-final, przez co napotykamy na błędy choćby takie jak:
Fantastyczne rozwiązanie tego problemu podaje Antonio Leiva w swoim artykule.
Adnotacja open pozwala także nadpisywać funkcje oraz wartości klas nadrzędnych.
W przykładzie użycie funkcji private oraz protected ogranicza się do jednej klasy. Z kolei public i internal pozwalają je wywołać w klasie dziedziczącej.
Klasy Enum nie różnią się wiele od tych z Javy. W skórcie pozwalają one na zdefiniowanie zbioru możliwych wartości.
Dzięki takiemu zabiegowi wiemy, że funkcja printDirection() zawsze dostanie parametr typu Direction.
Dla klas enum możemy zdefiniować konstruktor i reprezentować je choćby tak:
Sealed classes są rozszerzeniem klas enum. Reprezentują one hierarchiczną reprezentację danego typu z ograniczonego zbioru.
Kolejny raz Antonio Leiva w obrazowy sposób ukazuje ideę sealed classes.
Obiektami klasy Operation mogą być class lub data class dziedziczące po niej.
W Kotlin'ie najczęściej wykorzystuje się je w połączeniu z when.
W tym przypadku jako drugi paramtery możemy przekazać obiekt typu Operation, a co za tym idzie skończony zbiór możliwych operacji.
Jeżeli wypełnimy wszystkie przypadki dla Operation to nie wymagane będzie przez kompilator użycie else.
Na sam koniec nadmienię tylko, że sealed classes są zawsze abstrakcyjne oraz mają zawsze prywatny konstruktor.
Inline Classes zostały wprowadzone od wersji 1.3 i obecnie są oznaczone jako experimental.
Nie przeszkadza to jednak, żeby nieco o nich opowiedzieć.
Nazwa nawiązuje do Inline Functions, które to rozwiązują problem memory overhead dla funkcji wyższego rzędu.
Cała idea polega na tym, żeby obudować jakiś typ np. String zrozumiałym dla nas obiektem.
Problem pojawia się wtedy, gdy chcemy obudować typy prymitwne. Kompilator pod względem wydajności traktuje je inaczej.
Używając zwykłej klasy, tracimy skok wydajnościowy związany z prymitywami.
Krótko mowiąc, Kotlin przenosi taką klasę na stronę wywołania przez co problem wydajności znika.
Więcej o Inline Classes napiszę, kiedy staną się one Stable. Tymczasem ja dziękuję Ci za przeczytanie tego artykułu i zachęcam do sprawdzenia pozostałych :)
Zachęcam cię do odwiedzenia mojej strony na Google Play store i sprawdzenia wszystkich moich aplikacji.