Czy w Javie prywatni pomocnicy powinni przewyższać metody publiczne? [Zamknięte]

Zauważyłem, że współpracownik i ja mamy przeciwne praktyki dotyczące porządkowania metod w naszych klasach Java. Jeden z nas rozpoczyna klasę swoimi głównymi metodami publicznymi, a następnie oddaje wszystkich prywatnych pomocników. Drugi z nas upewnia się, że publiczne metody są na samym końcu.

Oczywiście jest to tylko kwestia stylu i nie ma właściwej odpowiedzi. Zanim jednak zdecydowaliśmy, że sprawa jest tylko kolejną walką Yooks vs. Zooks i po prostu wybrałem jedną lub drugą dowolnie, zastanawiałem się, czy może istniała standardowa rekomendacja przewodnika po stylu Java lub jakiś praktyczny powód, dla którego jedno podejście jest lepsze od drugiego.

Chociaż normalnie sprowadza się to do preferencji, z pewnością powinieneś starać się przestrzegać wspólnego standardu w swojej organizacji. Cokolwiek wybierzesz, wybierz standard i uniwersalnie go zastosuj.

Jeśli chodzi o wybór, jeśli zastosujesz się do sugestii zawartych w Czystym Kodzie , będziesz mógł przeczytać plik od góry do dołu jak artykuł w gazecie, co naturalnie sugeruje, że metody pomocnicze pojawiają się po metodach, którymi są agregat. Doprowadziłoby to do maksymalnej czytelności struktury kodu. Więc gdybyś miał

public void doSomething()
{
     helpMe();
     helpMeAgain();
}

Twój plik będzie miał następującą strukturę

public void doSomething() { }
private void helpMe() { }
private void helpMeAgain() { }

Innym skutkiem ubocznym jest to, że odkrywasz, że twoi pomocnicy mają swoich własnych pomocników, i pomaga ci dowiedzieć się, co naprawdę masz, to inna klasa żyjąca w twoim pliku, i możesz czysto zreformować, aby wyodrębnić go do własnej klasy, ponieważ te metody są już zgrupowane w kolejności. Ale to dodatkowa korzyść.

Metody publiczne są interfejsem klasy. Ktoś zainteresowany skorzystaniem z twojej klasy będzie dbał tylko o interfejs. Z punktu widzenia użytkownika klasy przydatne byłyby najpierw publiczne metody ograniczania przewijania.

W C i C ++ metody pomocnicze są często stawiane na pierwszym miejscu, ponieważ wtedy nie potrzebujesz deklaracji. Wiele osób przeniosło ten nawyk na inne języki, gdzie nie ma to znaczenia.

Wolę publiczne metody na górze, ponieważ zwykle kiedy otwieram plik, szukam jego publicznego interfejsu. Nie chcę przewijać wszystkich szczegółów implementacji. Zdarza się również, że jest to najpopularniejszy styl, jaki widziałem, więc można to powiedzieć o konwencji.

Podoba mi się porządek metod w klasie oparty na czytelności i kontekście, a nie widoczności.

tzn. metoda „otwarta” prawdopodobnie należy do „zamknięcia”. Jeśli dwie publiczne metody „a” i „b” wywołują prywatną „c”, a tylko one ją nazywają - wtedy podoba mi się, że „c” jest obok nich.

Nie sądzę, że konwencja porządkowania metod oparta na widoczności jest dobra.

Wolę widzieć moje klasy, w których członkowie są umieszczeni na liście według ważności / widoczności (tutaj przez znaczenie mam na myśli, że mają bezpośredni wpływ na interfejs publiczny).

Zatem funkcje prywatne mają tendencję do zepchnięcia na dół.

Istnieją wyjątki od tego, w którym będę również miał tendencję do grupowania podobnych funkcji razem, więc nadal można znaleźć małe prywatne funkcje zmieszane z publicznością.

To, jak powiedziałeś, kwestia gustu.

Jednak pracując nad kodem, który nie jest mój, postaram się przestrzegać wszelkich konwencji użytych w projekcie.

Jednym ze sposobów, w jaki udało mi się to śledzić, jest (zakładając, że tutaj pracujesz z Eclipse) utworzenie konfiguracji formatowania kodu i wyeksportowanie go ze źródłem projektu i przekazanie go do kontroli źródła. W ten sposób najnowsza i najlepsza konwencja kodu dla projektu jest zaledwie kilka kliknięć, aby skonfigurować, a nawyk CTRL-SHIFT-F przed popełnieniem nie pozwoli na wiele argumentów.

Dodatkową zaletą używania automatycznych formatatorów jest to, że możesz robić rzeczy w dowolnej konwencji, która cię uszczęśliwia i po prostu sformatować kod przed zatwierdzeniem. YMMV w zależności od wspomnianej konwencji i narzędzia formatującego.