Co modyfikator mówi o metodzie

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.

7 myśli na temat “Co modyfikator mówi o metodzie

  1. Uff, już się bałem, że tytuł notki na moim rss to wysublimowane nawiązanie do poprzednich wpisów. Miło widzieć, że programista wrócił do programowania, a.. hmm.. reszta zajmuje się tym co zawsze 😛

  2. Ciekawe. Nigdy nie wpadła mi myśl aby wszystkie private robić statyczne. Pewnie dlatego, że nie wszystkie mógłbym mieć statyczne:-)

  3. A Ja testuję metody prywatne reflectem i się tego nie wstydzę 🙂 Spring oraz Apache Commons dostarczają stabilne narzędzia do tego celu i wg mnie grzechem jest z nich nie skorzystać. Uważam, że nie powinno się dyskryminować metod prywatnych tylko dlatego, że trudniej je wywołać. Im też należy się odrobina TDD 😛

  4. @Henryk Konsek, oczywiście czasami trzeba coś napisać i przetestować. Jednak to co prywatne powinno takie zostać. Jeżeli jakaś metoda prywatna wymaga odrębnego testowania ponieważ realizuje złożone zadanie i nie za bardzo idzie je podzielić na mniejsze to warto ją przenieść do niepublicznego helpera. Testujesz wtedy helpera.

  5. Pomiędzy metodą do bólu prostą, a taką zasługującą już na helpera, jest jednak pewna nisza. Niszę ową idealnie wypełnia właśnie reflect 🙂

Napisz odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax