Zalety używania typealiases

Jakie są zalety typealiases? Czy faktycznie zwiększa to czytelność gdy zamiast

fun foo(id:String)

jest

fun foo(id:Id)

czy chodzi o coś innego?

Jako wady słyszałem, że ludziom szybciej jest kiedy wiedzą jak stworzyć to co mają przekazać, niż szukać definicji czym dokładnie to jest.

Za dokumentacją:

Type aliases provide alternative names for existing types. If the type name is too long you can introduce a different shorter name and use the new one instead. It's useful to shorten long generic types

Użycie aliasów zwiększa czytelność, zobacz podane tam przykłady:

typealias NodeSet = Set<Network.Node>
typealias FileTable<K> = MutableMap<K, MutableList<File>>
typealias MyHandler = (Int, String, Any) -> Unit
typealias Predicate<T> = (T) -> Boolean

Przykład, który podałeś jest nietrafiony - w tym przypadku użyłbym data class lub inline class, aby mieć ochronę typów. Natomiast odnośnie:

Jako wady słyszałem, że ludziom szybciej jest kiedy wiedzą jak stworzyć to co mają przekazać, niż szukać definicji czym dokładnie to jest.

To już kwestia przyzwyczajenia, ale efektywniej się pracuje, gdy nie musisz zaglądać w szczegóły implementacyjne klasy, której używasz (zaglądasz w bebechy ConcurrentHashMapy?). Oczywiście nie jest to łatwe do osiągnięcia, kwestia dotarcia się w zespole.

@danek wystarczy metoda która ma 3 inputy typu String i juz możesz sie łatwo pomylić. Oczyście tu warto rozważyc używanie data class jako value objectów, ale generalnie uważam że metoda która przyjmuje Email email jest czytelniejsza od tej przyjmującej String email - i mówię to z punktu widzenia doświadczenia komercyjnego a nie projekcików do szuflady :P

danek napisał(a):

Jako wady słyszałem, że ludziom szybciej jest kiedy wiedzą jak stworzyć to co mają przekazać, niż szukać definicji czym dokładnie to jest.

Potwierdzam przedmówców.
Natomiast co do tego powyżej to chyba pierwszy raz słyszałem w wersji: panie ja tam wolę mieć wszystko w jednej metodzie niż skakać po kodzie ( i patrzeć co się za tym kryje).

@jarekr000000:
@scibi92
Dla mnie też to wydaje się dobry pomysł. Argumentem tam było to, że jak masz email:Email, to nie wiesz od razu jak tego Email stworzyć (czy stworzyć obiekt, czy coś innego)

@danek: zazwyczaj wtedy stosuje się jakąś konwencję, np. zakłada że value objecty mają metode wytwórcza of np. Email.of(String). Zreszta naprawde skoczenie do implemetancji jakieś klasy az tak trudne nie jest...

Wyobraź sobie że masz metodę która przyjmuje dwa UUID, które dotyczą zupełnie innych encji. Szansa na pomylenie się kiedyś w kolejności to 50% :) O kwiatkach w stylu Map<String, Map<UUID, Map<String, String>>> to nawet nie warto mówić ;] Dużo prościej czyta się kod kiedy widzisz że metoda przyjmuje UserID oraz ProductID a nie dwa UUID.

Shalom napisał(a):

Wyobraź sobie że masz metodę która przyjmuje dwa UUID, które dotyczą zupełnie innych encji. Szansa na pomylenie się kiedyś w kolejności to 50% :) O kwiatkach w stylu Map<String, Map<UUID, Map<String, String>>> to nawet nie warto mówić ;] Dużo prościej czyta się kod kiedy widzisz że metoda przyjmuje UserID oraz ProductID a nie dwa UUID.

Nie wiem czy dobrze rozumiem aliasy w Kotlinie, ale czy kompilator jakoś to sprawdza?
W sensie jeśli mam:

typealias UserID = UUID
typealias ProductID = UUID

oraz metodę

fun buy(userId: UserID, productId: ProductID)

to czy kompilator coś krzyknie jeśli wywołam

buy(productId, userId)

Bo jeśli nie krzyknie to podniesienie bezpieczeństwa jest niewielkie i o wiele lepiej urzycać data class lub czegoś podobnego

@Kamil Żabiński:

Takie coś się skompiluje

typealias A = String
typealias B = String

fun main() {
    val a: A = "a"
    val b: A = "b"
    foo(a, b)
}

fun foo(a: A, b: B) {
    println("$a $b")
}

@Shalom

Dużo prościej czyta się kod kiedy widzisz że metoda przyjmuje UserID oraz ProductID a nie dwa UUID.

Jaka jest tutaj zaleta typealiases nad nazwą zmiennej?

Zaleta jest raczej przy refaktoringu. Jak któregoś dnia UserID się rozrośnie (bywa) to wtedy łatwiej wyszukać co trzeba zmienić bez uszkadzania sąsiadów.
Szczególnie jeśli mamy wiele modułów, a nawet projektów.
Więcej, od kiedy mam typealiasy to często robie sobię takie kadłubkowe klasy - typo Map<ID, CośTam> nawet jeśli wiem, ze na 99% trzeba będzie wprowadzić pełną klasę zamiast mapy. DictionaryCośTam nie wygląda źle, a jak nadejdzie czas to łatwo podmienić na pełną klasę.