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.