DevCezz

Programistyczny blog dla Ciebie

Zapomniany package private
Java Programowanie Usprawnienia

Zapomniany package scope

W serii poświęconej zawiłościom języka Java przedstawiłem modyfikatory dostępu, z których możemy korzystać, gdy projektujemy np. metodę, klasę czy pole w Javie. Dzięki nim jesteśmy w stanie hermetyzować nasz kod czy wskazywać co jest publicznym API dla innych programistów. Jednak jeden z tych modyfikatorów został zapomniany przez wielu deweloperów. Być może dlatego, że nie posiada on żadnego słowa kluczowego? 🤔

Zapomniany package scope

No właśnie, zapomniany modyfikator dostępu default zwany inaczej package scope. Dlaczego jest on pomijany? Być może przez tutoriale uczące nas konstrukcji zawartych w frameworku takim jaki np. Spring. Twórcy tych kursów skupiają się w głównej mierze na przekazaniu wiedzy dotyczącej narzędzia a nie na architekturze. Z tego powodu stosują prostą w zrozumieniu architekturę warstwową (potocznie nazywaną Lasagne). Jak sama nazwa wskazuje aplikacja zostaje podzielona na warstwy, najczęściej trzy: controller, service i repository.

Konsekwencją tego jest, że praktycznie wszystkie stworzone klasy muszą być publiczne, aby mogły się one ze sobą komunikować. I tak oto w ten sposób tworzyliśmy swoje pierwsze aplikacje, bo skoro twórcy frameworka właśnie tak nas nauczają to jest to na pewno święta prawda. Kto nie był w tym miejscu niech pierwszy rzuci kamień!

Jednak jeszcze raz powtórzę, ten podział kodu powstał, aby w szybszy sposób zapoznać się z mechanizmami rządzącymi frameworkiem. Nie ma w tym ani krzty architektury, która była by przyjazna dla użytkownika kodu, oczywiście w przypadku projektowania skomplikowanych procesów biznesowych. Sama architektura warstwowa jest bardzo pomocna przy prostych aplikacjach typu CRUD.

Przykład kodu

Załóżmy, że mamy mikroserwis czy też moduł odpowiedzialny za obsługę koszyka klienta w aplikacji e-commerce. W klasycznym podejściu jeżeli w ogóle nie martwilibyśmy się modyfikatorami dostępu nasz kod mógłby wyglądać następująco.

Zielone kłódki przy nazwach klas czy interfejsów wskazują, że są one publicznie dostępne. Wchodząc do takiego pakietu od razu nasuwa się pytanie: „Od czego, do jasnej ciasnej, ja mam zacząć?”. Przez to, że nie mamy jasnej deklaracji z czego możemy korzystać to pewnie każdy z nas brałby na zewnątrz tego pakietu co popadnie. Właśnie w ten sposób robi nam się przepyszne spaghetti, które z czasem zaczyna się psuć aż do momentu, gdy jest w ogóle nie do ruszenia. Można by tego wszystkiego uniknąć korzystając z zapomnianego modyfikatora package scope.

Teraz widzimy, że możemy skorzystać tylko z DTO, wyjątków oraz fasady. Nic więcej nas nie interesuje. Jeżeli już coś mielibyśmy zmieniać w tym pakiecie to na pewno zaczęlibyśmy przeszukiwanie właśnie od klasy CartFacade. Czytelne, proste i łatwe w obsłudze.

Nawet korzystanie ze Springa w tym momencie nie musi być kłopotliwe, ponieważ klasy oznaczone adnotacją @Configuration czy @RestController nie muszą być publiczne. Wszystko możemy mieć pięknie zhermetyzowane.

Podsumowanie

Tą ważną lekcję wyniosłem z wykładu Jakuba Nabrdalika pt. Modularity and hexagonal architecture in real life wygłoszoną w 2017 na warszawskim JUGu. Zachęcam do jego obejrzenia, naprawdę warto.

Dodatkowo polecam, aby domyślnie usunąć sobie dodawanie słowa kluczowego public przy każdym tworzeniu nowej klasy czy enuma. Robi się to przez wejście do ’File -> Settings -> Editor -> Code Style -> Java – > Code Generation’ i wybranie 'Default Visibility: Package local’.

Jeśli chcesz włączyć sobie przy klasach pogląd na modyfikatory dostępu w postaci np. zielonych kłódek to przy zakładce 'Project’ po lewej masz takie koło zębate. Naciskając je rozwinie Ci się lista dostępnych opcji i należy wybrać ’Show Visibility Icons’.

Mam nadzieję, że ten artykuł pomoże Ci pisać jeszcze lepszy kod niż dotychczas!

Podziel się tym z innymi!

2 KOMENTARZE

  1. Co do całości to oczywiście zgoda.

    Jedynie odnośnie „…klasy oznaczone adnotacją @Configuration czy @RestController nie muszą być publiczne. „, niekoniecznie. Sonar qube się czepia jeśli rest controller/jego metoda nie jest publiczna.
    Pokazuje to chyba jako smell code jeśli dobrze pamiętam.
    Nie pamiętam już uzasadnienia, ale to może mieć sens. Ukrywanie czegoś co w praktyce i tak jest dostępne, bo jest API apki może wprowadzać trochę w błąd, że można je pominąć. Dla innych pakietów nie jest dostępne, ale jest dostępne z zewnątrz.

    • Cześć Janusz!

      Dzięki za komentarz! 🙂 Rozumiem Twój punkt widzenia, jednak akurat sam bym nie polegał na SonarQube, bo to tylko narzędzie. Najlepiej jest się po prostu dogadać z zespołem czy chcemy robić pakietową konfigurację czy nie.

      Niemniej jednak faktycznie na plus takiego rozwiązania może być to, że widzimy co na wejściu jest konfiguracją. Z drugiej strony sama nazwa może nas o tym poinformować np. `BankConfig`. Dostęp pakietowy konfiguracji czy kontrolera też nie przyciąga wzroku i deweloper wchodzący do takiego pakietu od razu wie od czego ma zacząć. Springowi dostęp pakietowy tych elementów nie przeszkadza, więc może warto z niego korzystać. 🙂

Możliwość komentowania została wyłączona.