Jako, że poprzedni wpis wywołał tzw. „shitstorm” to liczę po cichu, że i ten ktoś przeczyta i co ważniejsze zastosuje…

W javie mamy cztery modyfikatory dostępu dla metod public, private, protected i default. Kolejność nieprzypadkowa ponieważ IMO taka jest „popularność” ich użycia. Przy czym pamiętajmy słowo kluczowe default nie jest obowiązkowe. Każdy z tych modyfikatorów ma pewne znaczenie nie tyle semantyczne co odzwierciedla ideę stojącą za metodą. Przynajmniej powinien. Chciałbym wam przybliżyć co każdy z nich reprezentuje.

Modyfikator public

Jest to najpopularniejszy modyfikator dla metod. Oznacza, że dana metoda należy do publicznego API klasy. Metoda taka jest „metodą znaczącą”, czyli niesie ze sobą jakiś scenariusz biznesowy czy też spójną funkcjonalność. Metody te powinny posiadać aktualną dokumentację oraz być przetestowane na wszelkie możliwe sposoby.
Co ważne metody te mają niemodyfikowalną sygnaturę. Oznacza to, że chcąc zachować kompatybilność wsteczną nie możemy zmieniać sygnatur tych metod. Jedynym rozsądnym wyjściem jest oznaczenie ich jako @deprecated i aktualizacja dokumentacji.
Trzeba też zadbać by metody te były łatwe w użyciu. Niewielka ilość parametrów oraz spójne zarówno wejście jak i wyjście powinny być grzecznością tych metod. Należy pamiętać, że metody o tej samej nazwie, ale różnej liście parametrów powinny zachowywać się w spójny sposób. Zatem jeżeli podanie wartości null powoduje NPE to oznacza to, że w każdej metodzie, której mamy parametr o tym samym znaczeniu biznesowym podanie null da NPE.

Modyfikator private

Jest przeciwieństwem public. Metod tych co do zasady nie testujemy, a dokumentacja choć powinna być to nie jest wymagana w pełnym zakresie. Metody te powinny być w miarę krótkie. Zawierają one kolejne, niepodzielne kroki danego algorytmu. Przy czym należy pamiętać, że duża ilość tego typu metod może oznaczać konieczność wydzielenia klasy, która przejmie na siebie część odpowiedzialności.
Warto też zwrócić uwagę na pewien ciekawy argument, a mianowicie metody prywatne powinny być statyczne. Mam obecnie pewien mały projekt to zrobienia w fabryce i zastosuję się do tego. Z ciekawości.

Modyfikator protected

Moim zdaniem najciekawszy ponieważ daje ogromne możliwości modelowania klas. Jeżeli programujemy w oparciu o interfejsy metody tego rodzaju pozwalają na uzyskanie namiastki programowania funkcyjnego. Dzięki nim możemy budować uogólnione algorytmy biznesowe, a konkretne implementacje poszczególnych elementów dostarczać w ramach dziedziczenia.
Metody te są dość trudne do testowania i raczej nie powinny być samodzielnie poddawane testom. Warto jednak poświęcić trochę czasu na próbę ich testowania ponieważ testy pozwolą na sprawdzenie fragmentów algorytmu.

Modyfikator default

… czyli nieszczęsna widoczność pakietowa. Używasz? Pewno nie. Rzeczywiście jest to dość specyficzny modyfikator. W Scali zrezygnowano z niego i domyślną widocznością jest public. Do czego może to służyć? Po pierwsze do tworzenia „pakietowych helperów”. Czasami jest tak, że w danym pakiecie potrzebujemy klasy narzędziowej, która poza pakietem nie ma sensu. Tu jest miejsce dla tego modyfikatora.
Metody te nie mają znaczenia od strony biznesowej, ale są bardzo istotne od strony technicznej i dlatego powinny podlegać takiemu rygorowi jak metody publiczne z wyłączeniem niezmienności. To ostatnie wynika z faktu, że metody takie nie są używane przez klientów zewnętrznych i mamy kontrolę nad tym gdzie są wywoływane.
Problemem mogą być testy. W zależności od przyjętego modelu organizacji testów może zachodzić potrzeba pośredniego wywołania metody za pomocą reflection api, ale takie przypadki należą do rzadkości. Zazwyczaj, maven jak i pluginy do IDE przestrzegają tego założenia, testy dla danej klasy znajdują się w tym samym pakiecie, ale w innym katalogu. JVM ładując klasy nie zwraca uwagi na katalogi, a właśnie na pakiety. Zatem klasy testowe widzą testowane metody z tego samego pakietu niezależnie od tego czy pochodzą z tej samej paczki czy też nie.

Podsumowanie

Modyfikator jest pierwszą rzeczą na jaką zwracamy uwagę patrząc na metodę. Warto zatem pamiętać, że za pomocą modyfikatora można zgrabnie udokumentować znaczenie metody w API. To przekłada się na szybkość eksploatacji API i poprawia jego zrozumienie.