W jakiej kolejności definiować osoby pobierające i ustawiające? [Zamknięte]


14

Czy istnieje najlepsza praktyka dotycząca definiowania getterów i settererów w? Wydaje się, że istnieją dwie praktyki:

  • pary getter / seter
  • najpierw pobierający, a następnie ustawiający (lub na odwrót)

Aby podkreślić różnicę, oto przykład Java par getter / setter:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public int getVar2() {
    return var2;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

A oto przykład Javy dla pierwszych pobierających, a następnie ustawiających:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public int getVar2() {
    return var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

Myślę, że ten drugi rodzaj porządkowania jest jaśniejszy zarówno w kodzie, jak i na diagramach klas, ale nie wiem, czy to wystarczy, aby wykluczyć inny rodzaj porządkowania.

Odpowiedzi:


8

Pierwszy sposób Jeśli to możliwe, zawsze grupuj razem lub trzymaj się blisko dzięki powiązanym funkcjom, które działają na tych samych elementach.

Jeśli ułożysz kod w ten sposób, dzięki temu będzie łatwiej i bardziej przejrzysto refaktoryzować, ponieważ jeśli jedną klasę można rozdzielić na drugą, która robi zbyt wiele, fragment podlegający rozkładowi zwykle obraca się wokół określonej zmiennej składowej.

Zasadniczo łatwiej jest debugować, rozumieć i manipulować kodem, gdy widać wszystko na tej samej stronie przez cały cykl życia obiektu / zmiennej. Chciałbym powiedzieć, że układ kodu oparty głównie na powierzchownościach, takich jak zakres i kolejność alfabetyczna, faktycznie oznacza, że ​​przegapisz możliwości refaktoryzacji, ponieważ ich nie widzisz.


Czy chciałbyś dołączyć jeszcze jeden argument za tym, dlaczego funkcje działające na tych samych elementach powinny być trzymane razem?
NN

Dodano kilka powodów.
Benedykt

25

Jeśli jesteś w zespole, rób to, co zwykle. W przeciwnym razie wybierz ten, który bardziej Ci się podoba. W skali ważnych wyborów projektowych jest to prawdopodobnie gdzieś w pobliżu „jakim kciukiem powinienem użyć klawisza spacji?”


7
Zgadzam się całkowicie. Znajduje się to pod nagłówkiem „nie przejmuj się małymi rzeczami”, co powinno być standardową zasadą kodowania dla wszystkich nr 0 ( jest to reguła nr 0 w „Standardach kodowania C ++” autorstwa Herb Sutter i Andre Alexandrescu.)
David Hammen,

Jestem pewien, że ludzie dużo się kłócą, za pomocą którego kciuka powinni nacisnąć
klawisz

@Michael, ja też mam rację. Próbowałem używać wyłącznie lewej strony, ale było to niezwykle trudne, a moje pisanie zwolniło.
axblount

@axblount Jestem praworęczny, ale zawsze używaj mojego lewego kciuka. Po prostu wypróbowałem moje prawo i miałem to samo doświadczenie, które opisałeś. Z jakiegoś powodu również piszę „y” lewą ręką.
KChaloux,

6

Może to również zależeć od języka. W Javie żadna kolejność nie ma żadnej realnej korzyści, ale na przykład w języku C # masz pojęcie „właściwości”, które grupują moduł pobierający i ustawiający razem, więc w pewien sposób wymusza to porządkowanie. W języku takim jak C ++, w którym możesz chcieć różnej widoczności na obiektach pobierających i ustawiających (np. Ustawiacz prywatny, obiekt pobierający publicznie), prawdopodobnie zrobiłbyś coś przeciwnego, ponieważ modyfikator widoczności jest podawany raz dla wielu metod, a nie osobno dla każdej z nich .


5

O ile mi wiadomo, nie ma jednej konwencji. Sekcja Oracle Java Code Conventions na temat organizacji plików nie wspomina wprost o rozmieszczeniu programów pobierających i ustawiających, ale mówi:

Metody te należy pogrupować według funkcjonalności, a nie zakresu lub dostępności.

Nie zapewnia to żadnych wskazówek - mogę argumentować, że jedno z miejsc docelowych spełnia te kryteria.

Należy wziąć pod uwagę, że nowoczesne IDE pozwalają uzyskać więcej abstrakcyjnych widoków struktury plików niż jako składnik kodu tekstowego. To, w połączeniu z potężnymi narzędziami wyszukiwania, powinno ułatwić nawigację po plikach i znaleźć odpowiednie metody nawet w dużych plikach.

Na przykład Eclipse zapewnia widok konspektu, który pozwala sortować i filtrować metody i pola na różne sposoby oraz nawigować bezpośrednio do miejsca, w którym znajdują się w plikach. NetBeans miał podobną funkcjonalność i podejrzewam, że robi to również większość innych IDE.

Może to mieć znaczenie tylko wtedy, gdy czytasz kod poza swoim IDE. Przykładem może być użycie zewnętrznego narzędzia do przeglądania kodu lub przeglądanie delt z systemu kontroli wersji.

Najlepszym rozwiązaniem byłoby po prostu zachowanie spójności między plikami w projekcie. Znajdź standard, udokumentuj go i trzymaj się go.


1

Zgrupuj moduł pobierający i ustawiający dla pojedynczego pola razem, parami.

Grupowanie wszystkich pobierających razem i wszystkich ustawiających razem utrudnia określenie, które pola mają tylko pobierające, czy tylko ustawiające.

Kiedy czytam kod lub szukam konkretnej funkcjonalności, wyobrażam sobie, że klasa ma pola, z których każde ma getter i setter. Dla mnie nie ma sensu, aby klasa miała grupę pobierającą i ustawiającą, z których każda ma pola.


Argumentujesz więc, że metody pobierające dla pola powinny być sparowane z modułami pobierającymi dla tego pola, ponieważ ułatwia to przeglądanie, w jaki sposób obsługiwane są określone pola w klasie?
NN

To i konceptualny model tego, czym jest klasa. Zajęcia powinny być organizowane przede wszystkim według funkcjonalności. Podczas tworzenia klasy możesz zdecydować, że potrzebuje ona publicznie widocznego, zmiennego pola. To jest konceptualna „funkcjonalność”, a nie wyrażenie składniowe za pomocą metod pobierających i ustawiających.
M. Dudley,

0

Ever Java IDE może generować dla ciebie gettery i settery. Wystarczy skorzystać z tej funkcji i pozostawić kolejność tych metod, jak IDE ją stworzyło. To jest generowany kod, nie dotykaj go niepotrzebnie.


Zdaję sobie z tego sprawę. Jednak np. W Eclipse możesz wybierać między różnymi porządkami .
NN

Dobrze. Domyślna opcja „Pola w parach getter / setter” wydaje się bardziej przydatna, ponieważ możesz dodać więcej pól i wygenerować więcej akcesorów później, nie martwiąc się, która metoda jest dokąd, po prostu umieść obie na końcu.
user281377,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.