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

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

Zmienne klasowe (statyczne): najpierw zmienne klasy publicznej, następnie chronione, a na końcu prywatne.
Zmienne instancji: najpierw publiczne, następnie chronione, a na końcu prywatne.
Konstruktorzy
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