#programowanie #kotlin Programuje w javie, ostatnio zainteresowalem sie kotlinem i uderzyly mnie dwie rzeczy: 1. Niby kotlin prestrzega dobrych praktyk, tj. classy sa finalne domyslnie, jest val/var ale nie rozumiem dlaczego classy sa domyslnie public. W wiekszosci tutoriali za plus kotlina uwaza sie wlasnie powyzsze rzeczy, zgodnie ze slynna ksiazka Effective Java ale juz klasy zrobili publiczne. Wg mnie powinno byc odwrotnie, tak jak np. w javie sa package scope. 2. Wlasnie, package scope. Nie rozumiem tez dlaczego tego nie zaimplementowali a dali internal. Mam jakis modul/pakiet ktory zawiera classy ktore, niechce, aby byly widoczne poza pakietem. Jak mam to zrobic w kotlinie? Tworzyc kazdorazowo modul intellij/gradle/maven etc. ? Bez sensu, zwlaszcza kiedy teraz jest popularne package by feature not layer. W javie mam package scope i jesli chce zaznaczyc ze to jest kod wewnetrzny to mam package scope. W kotlinie albo wszystko jest dostepne, albo mam internal albo laduje wszystko do jednego pliku (co tez podobno jest nie tak dobra praktyka, bo nie widac tych class odrazu w strutkurze projektu).
@newbie_235235: Dali domyślnie public bo w javie i tak wszyscy to robią, protected jest dopiero w drugiej setce najczęściej używanych słów w javie Ogólnie enkapsulacja to mit, ludzie dają gettery i settery do wszystkiego. Też mi brakuje czasami protected ale jeżeli nie masz gigantycznych modułów to raczej nie powinien to być problem. Nie rozumiem jednak w czym przeszkadza to w package per feature?
@Bruno_: no to ze lwszyscy daja public to nie znaczy ze jest ok.
no to ze ludzie daja gettery/settery to nie znaczy ze to jest dobre. Pracowalem przy jednym projekcie, gdzie nie bylo zadnej enkapsulacji a wszystkie operacje opieraly sie na getterach/setterach i o zgrozo utilsach ktore zawieraly logike i operowaly na tych getterach/setterach. Gettery/settery poza dto to zlo.
No zalozmy, ze mam modul ktory cos wylicza w zaleznosci od
@newbie_235235: wszystko można i tak przez refleksje wydostać xD
Ogólnie internal to powinno się stosować w modułach z których korzystają inne projekty (libki) a nie w końcowych projektach (apki)
Wracając do pytania, modularyzuj tak samo xD po prostu odpada package private z którego i tak prawie nikt nie korzystał (a to czy powinni to inna sprawa). Ja w sumie jak przesiadłem się na kotlina to brakowało mi tego package private,
Programuje w javie, ostatnio zainteresowalem sie kotlinem i uderzyly mnie dwie rzeczy:
1. Niby kotlin prestrzega dobrych praktyk, tj. classy sa finalne domyslnie, jest val/var ale nie rozumiem dlaczego classy sa domyslnie public. W wiekszosci tutoriali za plus kotlina uwaza sie wlasnie powyzsze rzeczy, zgodnie ze slynna ksiazka Effective Java ale juz klasy zrobili publiczne. Wg mnie powinno byc odwrotnie, tak jak np. w javie sa package scope.
2. Wlasnie, package scope. Nie rozumiem tez dlaczego tego nie zaimplementowali a dali internal. Mam jakis modul/pakiet ktory zawiera classy ktore, niechce, aby byly widoczne poza pakietem. Jak mam to zrobic w kotlinie? Tworzyc kazdorazowo modul intellij/gradle/maven etc. ? Bez sensu, zwlaszcza kiedy teraz jest popularne package by feature not layer. W javie mam package scope i jesli chce zaznaczyc ze to jest kod wewnetrzny to mam package scope. W kotlinie albo wszystko jest dostepne, albo mam internal albo laduje wszystko do jednego pliku (co tez podobno jest nie tak dobra praktyka, bo nie widac tych class odrazu w strutkurze projektu).
Jak sensownie modularyzowac kod w kotlinie?
Dali domyślnie public bo w javie i tak wszyscy to robią, protected jest dopiero w drugiej setce najczęściej używanych słów w javie
Ogólnie enkapsulacja to mit, ludzie dają gettery i settery do wszystkiego. Też mi brakuje czasami protected ale jeżeli nie masz gigantycznych modułów to raczej nie powinien to być problem. Nie rozumiem jednak w czym przeszkadza to w package per feature?
no to ze lwszyscy daja public to nie znaczy ze jest ok.
no to ze ludzie daja gettery/settery to nie znaczy ze to jest dobre. Pracowalem przy jednym projekcie, gdzie nie bylo zadnej enkapsulacji a wszystkie operacje opieraly sie na getterach/setterach i o zgrozo utilsach ktore zawieraly logike i operowaly na tych getterach/setterach. Gettery/settery poza dto to zlo.
No zalozmy, ze mam modul ktory cos wylicza w zaleznosci od
Ogólnie internal to powinno się stosować w modułach z których korzystają inne projekty (libki) a nie w końcowych projektach (apki)
Wracając do pytania, modularyzuj tak samo xD po prostu odpada package private z którego i tak prawie nikt nie korzystał (a to czy powinni to inna sprawa). Ja w sumie jak przesiadłem się na kotlina to brakowało mi tego package private,