Ciao Tatiana,
imho é il problema perché riscrivendo quel modulo in Kotlin abbiamo smesso
di fare discussioni come questa.
Diciamo che architetturalmente ci piace avere un bean apposito ogni qual
volta saltiamo da un layer all' altro (quindi strategia `sempre e comunque`
perché é consistente e ci sembra più pulita) ma facendolo in Java troviamo
il processo molto tedioso e ci troviamo a chiederci quale sia il vantaggio
reale (e quindi discussioni sul come/quando/se).
Con Kotlin invece il codice è una frazione rispetto a quello in Java, è
molto più veloce creare bean e trasformarli e di conseguenza ci rompiamo
meno le scatole :)
Per farti un esempio, nei nostri endpoint REST, invece di avere n-mila
classi separate dei vari bean (che al momento creiamo manualmente), abbiamo
la definizione dei bean direttamente nel file che contiene il controller, e
solitamente si tratta di poche righe di codice perché cerchiamo di tenere i
controller piuttosto snelli (poche operazioni, quindi pochi bean di,
tendenzialmente, una riga di codice).
"""
data class User(val name: String, val age: Int)
@RestController
class UserController {
@GetMapping("/hello")
fun hello() = User("Andrea", 36)
}
"""
2018-01-17 8:44 GMT+01:00 Roberto Franchini [email protected]
[it-torino-java-jug] <[email protected]>:
>
>
>
>
> 2018-01-17 8:08 GMT+01:00 Federico Fissore [email protected]
> [it-torino-java-jug] <[email protected]>:
>
>>
>>
>> Tatiana Litvinova [email protected] [it-torino-java-jug] ha
>> scritto il 16/01/2018 alle 22:28:
>> > è *il* problema. L'interfaccia fluente con dei nomi dei metodi corti è
>> > più carina e più trendy, ma fa davvero tanta differenza nella sostanza?
>> > Le mappe... capisco i pro, ma l'assenza di un controllo sintattico
>> sulle
>> > chiavi mi fa paura. E il refactoring?
>> >
>>
>> Capisco e condivido la preoccupazione. Ma ai tempi pensai: in javascript
>> faccio già così e lo so fare, in java può solo essere più facile.
>> E lo confermo: quasi all'improvviso ti trovi senza annotazioni, senza
>> librerie di mapping, senza boilerplate. Solo ciccia. Codice più breve,
>> più facile da testare.
>>
>> It's my time.
> Quando Fede ebbe la prima visione, io c'ero.
> E la seguii.
> Cosi' tanto che ancora oggi esiste un sistema, che gestisce qualcosa come
> 10 milioni di messaggi al giorno, che usa quel modo di sviluppare.
> Ne ho riscritta una incarnazione, da zero , in Kotlin (spero di metterla
> OS presto).
> Perche' e' flessibile, testabile, facile fare ingestione dei dati da fonti
> diverse e normalizzarli.
> Ci sono un paio di talk, uno suo ed uno mio, un po' datati, tra i video
> del JUG, mi pare il titolo sia Kill Bean 1 e 2
>
> FRANK
>
>
>
> --
> Roberto Franchini
> "The impossible is inevitable"
> https://github.com/robfrank/
> https://twitter.com/robfrankie
> https://www.linkedin.com/in/robfrank
>
>
>
--
** Think about the environment before printing
