Czy istnieją konwencje porządkowania metod w języku Java? [Zamknięte]

159

Mam dużą klasę (około 40 metod), która jest częścią pakietu, który będę przesyłał w ramach kursu. Obecnie metody są dość pomieszane pod względem użyteczności publicznej / prywatnej itp. I chcę je uporządkować w rozsądny sposób. Czy jest na to standardowy sposób? Np. Normalnie pola są wymienione przed metodami, konstruktor (y) są wymienione przed innymi metodami, a metody pobierające / ustawiające są na końcu; co z pozostałymi metodami?

java methods conventions fredley
źródło
Zwróć również uwagę, że podczas pracy z takim kodem większość IDE umożliwia automatyczne wyświetlenie definicji tego, co znajduje się pod kursorem. Oznacza to, że nie musisz nic robić poza spojrzeniem.
Thorbjørn Ravn Andersen
Jeśli masz 40 metod w jednej klasie - robisz to źle
Ben

Odpowiedzi:

132

Niektóre konwencje wymieniają najpierw wszystkie metody publiczne, a następnie wszystkie prywatne - oznacza to, że łatwo jest oddzielić API od implementacji, nawet jeśli nie ma interfejsu, jeśli rozumiesz, o co mi chodzi.

Innym pomysłem jest zgrupowanie powiązanych metod razem - ułatwia to dostrzeżenie połączeń, w których można podzielić istniejącą dużą klasę na kilka mniejszych, bardziej ukierunkowanych.

Jon Skeet
źródło
1
+1. Wolę sortować według widoczności. Shame Eclipse nie może tego zrobić automatycznie (zawsze
grupuje
16
@finnw, zgłoś błąd. Stamtąd zaimplementowano dziwniejsze rzeczy.
Thorbjørn Ravn Andersen
3
@Ben: Z mojego doświadczenia wynika, że ​​każdy „nigdy” nie będzie miał wyjątków.
Jon Skeet
1
@JonSkeet w kilku przypadkach, gdy konwencje porządkowania nie są już istotne, na przykład testuj klasy. Lepiej nie pisać złego kodu niż układać zły kod.
Ben
1
@Ben: Myślę, że będziemy musieli się zgodzić, aby się nie zgodzić. Napisałem kod, w którym jest bardzo naturalnie wielu członków, bez naruszania jakiegokolwiek podziału obaw itp.
Jon Skeet
121

  1. Zmienne klasowe (statyczne): najpierw zmienne klasy publicznej, następnie chronione, a na końcu prywatne.

  2. Zmienne instancji: najpierw publiczne, następnie chronione, a na końcu prywatne.

  3. Konstruktorzy

  4. Metody: metody te powinny być pogrupowane według funkcjonalności, a nie zakresu lub dostępności. Na przykład metoda klasy prywatnej może znajdować się między dwiema metodami wystąpienia publicznego. Celem jest ułatwienie czytania i rozumienia kodu.

Źródło: http://www.oracle.com/technetwork/java/codeconventions-141855.html

Michael
źródło
4
To ma 15 lat i prawdopodobnie jest trochę przestarzałe ze względu na wygląd nowoczesnych IDE ...
assylias
16
@assylias: IMO, czytelność jest niezależna od IDE. Zwykle lepsze jest zachowanie publicznego przed prywatnym.
saurabheights
40

Bardziej precyzyjny link do „Konwencji kodowych”: „Deklaracje klas i interfejsów”

Timofey Gorshkov
źródło
8
+1, afaik - to JEDYNY wpis, który faktycznie odpowiada na to pytanie. TAK istnieje standardowa kolejność podyktowana przez Oracle i Sun: 1. komentarz publiczny, 2. klasa, 3. komentarz wewnętrzny, 4. dane statyczne, 5. dane instancji, 6. ctors, 7. metody oraz w ramach każdej grupy sekcji logicznie, a nie przez dostępność.
John Henckel
@VadimKirilchuk «Archiwum internetowe» nie działa…
Timofey Gorshkov
1
oracle.com/technetwork/java/codeconvtoc-136057.html
Elder Geek
15

Nie jestem pewien, czy istnieje powszechnie przyjęty standard, ale moje własne preferencje są;

  • najpierw konstruktorzy
  • następnie metody statyczne, jeśli istnieje metoda główna, zawsze przed innymi metodami statycznymi
  • następnie metody niestatyczne, zwykle według znaczenia metody, po której następują metody, które wywołuje. Oznacza to, że metody publiczne, które wywołują inne metody klas, pojawiają się na górze, a metody prywatne, które nie wywołują innych metod, zwykle kończą się na dole
  • standardowych metod, takich jak toString, equalsihashcode następne
  • Programy pobierające i ustawiające mają specjalne miejsce zarezerwowane na dole klasy
Qwerky
źródło
Naprawdę wolę konstruktory jako ostatnie, ponieważ poprawnie napisany konstruktor nie powinien robić nic poza przypisaniem swoich argumentów do właściwości.
GordonM
@GordonM Dlaczego tak myślisz? Posunąłbym się nawet do stwierdzenia, że ​​jest odwrotnie. Zawsze powinieneś pomyśleć o najczystszym API dla swoich klas. I często nie jest to sposób, w jaki są przechowywane, więc często wykonuję sporo przetwarzania, aby odciążyć dzwoniącego
Neuron
@GordonM Nie mówię o skutkach ubocznych. Więc żadnych zmian w listach, które zostały przekazane, ani niczego podobnego. Samo przekazanie i ustawienie wartości wymaga, aby klasa dużo mówiła o swojej implementacji, co nie powinno mieć miejsca
Neuron
@LonelyNeuron Nie jestem do końca pewien, co tu mówisz, ale wygląda na to, że mówisz, że konstruktor powinien wykonać dużo pracy konfiguracyjnej poza przypisaniem argumentów do stanu wewnętrznego. Jest to zdecydowanie złe, ponieważ oznacza, że ​​rzeczy dzieją się za pomocą „magii”. Wywołanie do new Thing()powinno skutkować jedynie utworzeniem wystąpienia nowej rzeczy. Nie powinno to powodować otwierania połączeń z bazami danych, zapisywania plików itp.
GordonM
@LonelyNeuron Posiadanie zależności w konstruktorze nie mówi nic o implementacji klasy poza tym, jakie są jej zależności. To dobra rzecz, a nie zła.
GordonM
12

40 metod w jednej klasie to trochę za dużo.

Czy miałoby sens przeniesienie części funkcjonalności do innych - odpowiednio nazwanych - klas. Wtedy znacznie łatwiej jest to zrozumieć.

Gdy jest ich mniej, znacznie łatwiej jest je wymienić w naturalnej kolejności czytania. Częstym paradygmatem jest umieszczanie listy rzeczy przed lub po tym, jak ich potrzebujesz, w takiej kolejności, w jakiej ich potrzebujesz.

Zwykle oznacza to, że main()znajduje się na górze lub na dole.

Thorbjørn Ravn Andersen
źródło
1
masz rację - to nie jest kwestia zamówienia
kostja
4
Nie zawsze masz wybór, na przykład jeśli implementujesz interfejs z wieloma metodami.
finnw
5
Jest to aktywny Android, więc istnieje wiele, że po prostu nie można się nigdzie indziej onPause(), onResume()itp, jak również wszystkich moich OnClickListenerpolach, które, chociaż są to pola, nie wyglądają lub zachowują się jak oni, więc jest to rozsądne wymień je osobno.
fredley,
@finnw, klasy abstrakcyjne są ładne i przydatne do tego celu.
Thorbjørn Ravn Andersen
11

Moja „konwencja”: statyczna przed instancją, publiczna przed prywatną, konstruktor przed metodami, ale główna metoda na dole (jeśli występuje).

eljenso
źródło
2

Ponadto eclipse oferuje możliwość sortowania członków klasy, jeśli z jakiegoś powodu ich pomieszałeś:

Otwórz plik klasy, przejdź do „Źródła” w menu głównym i wybierz „Sortuj członków”.

zaczerpnięte stąd: Metody sortowania w Eclipse

Stephan Richter
źródło
1

Czy używasz Eclipse? Jeśli tak, to trzymałbym się domyślnej kolejności sortowania, ponieważ jest to prawdopodobnie najbardziej znane każdemu, kto czyta Twój kod (chociaż nie jest to moja ulubiona kolejność sortowania).

finnw
źródło