Prowadziłem ostatnio warsztaty z Kotlina. Uczestnicy zadawali oczywiście sporo pytań – taki był zresztą plan. Jednak część z tych pytań naprawdę mnie zaskoczyła I nie chodzi o to, iż nie potrafiłem na nie odpowiedzieć – bo potrafiłem Chodzi o to, iż dotyczyły one spraw dla mnie tak „oczywistych”, iż po kilku latach kodowania w Kotlinie zupełnie przestałem je zauważać…
Ta sytuacja natchnęła mnie do napisania niniejszego posta. Zebrałem tu listę pozornie małych rzeczy – udogodnień, których na co dzień albo nie zauważamy, albo choćby nie wiemy o ich istnieniu, a które wyraźnie ułatwiają nam życie.
Co więcej, żadna z nich nie jest dziełem przypadku. Wszystkie zostały skrzętnie zaprojektowane w oparciu o błędy i doświadczenia innych języków – przede wszystkim Javy.
Koniec tego przydługiego wstępu. Zapraszam do lektury
1. Operator == działa jak equals() w Javie
Dość częstym błędem w Javie jest porównywanie obiektów dzięki operatora ==, i oczekiwanie wyniku działania metody equals(), np.:
User user1 = new User("John", "Smith"); User user2 = new User("John", "Smith"); System.out.println(user1 == user2); // ???Jak będzie wynik działania powyższego kodu?
Pokaż odpowiedź
Mimo iż instynktownie oczekiwalibyśmy true, dostajemy false.
Dlaczego? Dlatego iż w Javie operator == nie porównuje adekwatności/struktury obiektów, tylko sprawdza, czy referencje wskazują na to samo miejsce w pamięci. Ponieważ nasze referencje wskazują na dwa różne obiekty, to dostajemy false – niezależnie od faktu, iż te obiekty są identyczne.
W Kotlinie nie ma tego problemu. Operator == woła po prostu metodę equals() i tyle. Natomiast do porównywania wskaźników mamy, jak w wielu nowych językach, operator ===.
2. Parametry funkcji są finalne
Kolejną ciekawostką jest finalność parametrów funkcji/metod. Jak myślisz, jaki będzie wynik działania poniższego kodu w Javie?
public void appendTest() { String message = "abc"; append(message, "def"); System.out.println(message); // ??? } public void append(String msg, String suffix) { msg += suffix; }Pokaż odpowiedź
jeżeli myślałeś, iż "abcdef", to masz pecha. Zobaczysz tylko "abc".
Co się stało? Java źle działa? Oczywiście, iż nie Po prostu użyłeś operatora +=, który „przekierował” referencję msg w inne miejsce. Nadpisałeś ją. Przestała wskazywać na to samo miejsce co referencja message.
Jedynym znanym mi sposobem na tak podstępne błędy jest konsekwentne oznaczanie wszystkich parametrów metod jako final (np. final String msg). I znam kilka osób, które faktycznie tak robią…
Jak to jest w Kotlinie? Otóż wszystkie parametry są finalne. W ogóle nie ma możliwości ich „nadpisania”. Przy każdej próbie użycia operatora =/+=/*= itp. dostaniemy błąd kompilacji. Dlatego powyższy problem nigdy nie wystąpi.
3. override jest słowem kluczowym, a nie adnotacją
O ile adnotacja @Override w Javie NIE jest obowiązkowa, o tyle słowo najważniejsze override w Kotlinie – już jest. Dzięki temu wykluczamy kolejną grupę podstępnych błędów, np.:
// Klasa bazowa public class BaseClass { public void doSomething() { ... } } // Java // Obie poniższe klasy się kompilują, mimo iż jedna zawiera literówkę public class MyClass1 extends BaseClass { public void doSomething() { ... } } public class MyClass2 extends BaseClass { public void doSomethng() { ... } } // Kotlin class MyClass1 : BaseClass() { fun doSomething() { ... } // błąd kompilacji - brak "override" } class MyClass2 : BaseClass() { override fun doSomething() { ... } // OK } class MyClass3 : BaseClass() { override fun doSomethng() { ... } // błąd kompilacji - literówka }4. Nazwy metod mogą zawierać spacje…
Tak, to prawda Istnieje specjalna notacja umożliwiająca tworzenie metod, których nazwy mogą zawierać spacje i inne dziwne znaczki… Jednak trzeba tu jasno zaznaczyć, iż została ona stworzona wyłącznie z myślą o testach – i tylko tam powinno się jej używać, np.:
@Test fun `when password is wrong then throw an error`() { //your test logic }5. System typów i typ Nothing
Kotlin ma genialny, bardzo spójny system typów. Wszystko jest obiektem. Każdy typ dziedziczy po typie bazowym Any. Każdy typ ma swoją wersję nullowalną (np. String?, Int?) i nie-nullowalną (np. String, Int). Jest także singleton Unit, który (w dużym uproszczeniu) odpowiada słowu kluczowemu void z Javy.
Jednak nie każdy wie, iż istnieje też bardzo interesujący typ o nazwie Nothing. Cóż to takiego? Otóż, podczas gdy wszystkie typy dziedziczą po Any, to Nothing dziedziczy po WSZYSTKICH typach. Spróbujmy to zobrazować:
-> String -> -> Int -> Any -> List<T> -> Nothing -> User -> -> ... ->Nie będę tutaj wchodził w szczegóły (można o nich poczytać tutaj). Powiem tylko, iż dzięki takiej koncepcji, możemy tworzyć konstrukcje jak ta poniżej:
fun getAddress(user: User): Address { return user.address ?: throw Exception("Address required") }throw jest tutaj użyte jako wyrażenie (a nie instrukcja!). Wyrażenia zwracają wartość. Zgadnij jakiego typu jest wartość zwracana przez throw? Dokładnie – Nothing! A ponieważ Nothing dziedziczy po wszystkich typach, to dziedziczy również po naszym Address – i właśnie taki typ zwracamy z funkcji.
Również funkcja TODO(), którą na co dzień wykorzystujemy jako placeholder dla niezaimplementowanych funkcji, ma prawo bytu wyłącznie dzięki istnieniu typu Nothing:
fun doSomething(param: Boolean): String { if (param) { return "something" } else { TODO("Not implemented yet") } }I znów, możemy jej użyć niezależnie od typu wracanego przez funkcję.
6. switch na sterydach
Kto nigdy nie zapomniał o umieszczeniu break’a w switch-case, niech pierwszy rzuci kamień Według niektórych rankingów jest to najczęstszy błąd popełniany w Javie.
W Kotlinie pozbyto się go w prosty sposób – po prostu w ogóle nie trzeba pisać break’a
Wyrażenie when (często określane mianem switch’a na sterydach) porównuje kolejno każdy warunek, i gdy któryś jest zgodny – wykonuje dany branch. I tylko ten jeden branch – a nie wszystkie kolejne w dół. A jeżeli chcemy by ten sam branch wykonał się dla wielu warunków, to oddzielamy je przecinkiem:
when (x) { 1 -> print("one") 2, 3 -> print("two or three") else -> print("something else") }7. Sprecyzowanych typów nie trzeba manualnie rzutować
Kiedy sprawdzamy typ obiektu dzięki operatora is, kompilator Kotlina może się popisać funkcją określaną mianem „smart-casting”. Polega ona na tym, iż tak sprawdzonego typu nie musimy już manualnie rzutować (tak jakbyśmy musieli w Javie), np.:
val result = when (x) { is String -> x.length > 5 is Int -> x > 5 is Boolean -> x.xor(true) else -> false }Zauważ iż po prawej stronie -> dostajemy odpowiednio: String’a, Int’a i Bool’a, mimo iż niczego jawnie nie rzutowaliśmy.
8. when jako alternatywa dla if-else-if…
Mało kto wie, iż when może też przybrać specjalną, bezparametrową formę. Poszczególne warunki stają się wtedy zwykłymi wyrażeniami zwracającymi Bool’a, i mogą przyjmować dowolną logikę:
when { x > 5 -> print("greater than 5") isEven(x) -> print("is even") else -> print("none of the above") }9. Wieloliniowe Stringi
Chyba wszyscy wiedzą o interpolacji stringów – czyli funkcji, która pozwala zamieszczać wewnątrz Stringów symbole poprzedzone znakiem $:
val a = 1; val b = 2 println("$a + $b = ${a+b}") //prints: 1 + 2 = 3Natomiast nie wszyscy już wiedzą, iż Kotlin posiada także wieloliniowe Stringi:
val msg = """abc def ghi"""…oraz iż w nich również możemy zamieszczać symbole:
val name = "Grzegorz" val msg = """Hello, $name! How are you? Best regards, Admin"""A jakby tego było mało, możemy jeszcze użyć funkcji trimIndent(), która wycina wiodące spacje i puste linie:
val withoutIndent = """ ABC 123 456 """.trimIndent() // ABC\n123\n45610. Przekazywanie tablicy w miejsce vararg
Załóżmy iż mamy funkcję ze zmienną liczbą argumentów (vararg):
fun calculateSum(vararg elements: Int): Int { ... }Możemy do niej przekazywać pojedyncze elementy:
calculateSum(1, 2, 3)Lub, jeżeli mamy już gotową tablicę elementów, to możemy ją przekazać bezpośrednio, korzystając z tzw. „spread operator” (czyli prefiksu *):
val elements = arrayOf(1, 2, 3) calculateSum(*elements)11. Wygodna iteracja po Mapach
W Kotlinie możemy w łatwy sposób iterować jednocześnie po kluczach i wartościach:
for ((k, v) in map) { println("$k -> $v") }Warto zwrócić uwagę, iż NIE jest to żaden „przypadek szczególny”, żaden specjalny for dla Map. Korzystamy tu po prostu z mechanizmu dekonstrukcji obiektów – tego samego, który pozwala nam „rozkładać” na czynniki pierwsze np. data class’y.
12. Kotlin to nie tylko JVM!
Będąc developerem JVM łatwo zapomnieć, iż twórcy Kotlina nie ograniczają się tylko do tego jednego ekosystemu – pozostało Kotlin/JS i Kotlin/Native.
Kotlin/JS transpiluje kod Kotlina do JavaScriptu, co pozwala m.in. na pisanie front-end’ów webowych w React w Kotlinie (więcej info tutaj). Natomiast Kotlin/Native umożliwia kompilację kodu Kotlina do kodu natywnego dla Linuksa, macOS, iOS i Windowsa.
Tak więc już dziś możemy pisać w Kotlinie produkcyjne backendy (Spring, Vert.x, Ktor), frontendy (jQuery, React) i apki na Androida. A już niedługo także apki na iOS i desktopy. Aż strach pomyśleć, co będzie następne…?
Podsumowanie
Zdaję sobie sprawę, iż powyższa lista jest subiektywna, i zdecydowanie NIE jest wyczerpująca
Mimo to ciekaw jestem, czy wiedziałeś o wszystkich z powyższych? A może masz swoje ulubione „małe” rzeczy, ułatwiające codzienne życie developera? Podziel się w komentarzu
Z mojej strony to wszystko. Do następnego wpisu!
