Idąc za radami z prezentacji Nabrdalika o package scope: postanowiłem trochę się tym trochę pobawić. Efekt na prostej apce można zobaczyć tutaj: https://github.com/Sampeteq/ToDoListJava/tree/main. Skończyłem z dość dużym pakietem ze sporą ilością klas niby należącymi do tego samego kontekstu, ale wygląda to tak jakby prosiło się o jakieś dodatkowe podpakiety. Ktoś złośliby mógłby powiedzieć, że jeszcze tu nasrać tylko ( ͡º ͜ʖ͡º) Tak to ma wygladać czy ja coś schrzaniłem?
0
0
No na upartego to żeby podzielić Accounts mógłbyś zrobić CQRS'a i wydzielić pakiety to zapisu i do odczytu. No i dlaczego w pakiecie account masz klasy Task? Też bym pewnie to wydzielił do oddzielnej domeny/modułu. Trochę to wygląda jakby domeną aplikacji była aplikacja.
0
@MrMadMatt: Bo każde account ma swoje taski to raz a dwa, że wymusza to ten dostęp pakietowy.
3
Nic Ci żaden dostęp pakietowy nie wymusza. Konta i taski to dwa różne moduły, to że używasz do relacji klas zamiast typów podstawowych wymusza na Tobie taką implementację i to raczej kwestia JPA i ichniejszego podejścia "jedna encja do wszystkiego".
0
@MrMadMatt: To jakby to miało inaczej wyglądać, bo nie rozumiem? Przecież taski nie mogą istnieć bez kont. Każde konto ma swoje taski.
4
Przecież taski nie mogą istnieć bez kont
Nie wiem jak masz tam porobione i czy zadziała w Twoim przypadku, ale w ogólności to nie oznacza, że klasa Task musi mieć referencję do Account - możesz tak podzielić domenę na moduły, że Task ma tylko accountId . Albo/i odwrotnie, Account nie musi nic wiedzieć o zadaniach - w dużych aplikacjach wiele encji ma kontekst accounta, co nie oznacza, że wszystko jest wpychane do klasy/modułu Account. Czy do utworzenia/modyfikacji taska potrzebujesz wszystkich danych z Account?
Także zacząłbym od hipotezy, że te klasy w ogóle nie musza o sobie wiedzieć i zaczął iteracyjnie dodawać idki (jeśli to są różne moduły) i referencje (jeśli to jest ten sam moduł). Musisz oduczyć się myślenia w kategoriach relacji JPA i wrócić do modelowania komponentów i modułów na kartce :) Staraj się maksymalnie ograniczyć coupling - skup się na modelu do zapisu (projektowanie agregatów). To jest 100x ważniejsze niż package-private.
Tutaj video na ten temat
0
Warto też mieć na uwadze że od Javy 17 LTS gdzie pojawiły się sealed classy otwierają się nowe możliwości.