Wpis z mikrobloga

Package scope i architektura aplikacji - jak do tego podejść?

Co sądzicie o używaniu domyślnego modyfikatora dostępu (package sope) zamiast public? Ostatnio oglądałem prezentację Jakuba Nabrdalika, w której pokazywał zalety takiego podejścia. Głównie chodzi o to, że dzięki temu można enkapsulować klasy w obrębie jednego pakietu, który tylko wystawia jakieś publiczne api (fasadę) zamiast wszystkich klas, method itd. Brzmi rozsądnie tylko, że pojawią się takie problemy jak np. to, że w jednym pakiecie musi znajdować się dość sporo klas np. encje, value objecty, serwisy domenowe, interfejsy i ich implementacje, (np. repozytoria przez co warsta domeny miesza się z infrastrukturą), security itd. a same fasady wydają się mieć tendencje do puchnięcia, co wydaje mi się, że widać też u autora prezentacji, który ma fasadę, przyjmującą wiele innych klas i na ich podstawie wystawia publiczne api, które zajmuje się bardzo różnymi rzeczami i nie wiem czy czasem nie łamie to SOLIDu, bo potem takiej fasady z różnymi methodami musi używać jakiś np. ReadController, który będzie miał też dostęp nie tylko do methody read, ale też do update czy co gorsza delete, co nie jest zbyt bezpieczne. No i niewszystkie języki wspierają package scope, np. chyba Kotlin i C# tego nie mają, ale głowy sobie nie dam uciąć.

#programowanie #naukaprogramowania #programista15k #it
  • 1
via Wykop Mobilny (Android)
  • 0
@Edelner: zamiast pakietów możesz mieć moduły. Jedna wielka fasada też nie jest problemem: przecież możesz ją podzielić na kilka mniejszych, jeśli to ma sens. Naczelną zasadą jest minimalizowanie interfejsu, żeby kod aplikacji miał strukturę ładnego drzewa a nie grafu pełnego. Co do repozytorium: to przecież interfejs nie będący w żadnej warstwie. Warstwa infrastruktury to implementacja: możesz przykładowo stworzyć taką implementację w maine a następnie przepchać ją do fasady w konstruktorze.