Pobrać wartość za pomocą gettera czy odwołać się do pola?

Witam,
Mam dwa działające rozwiązania, tylko różnica jest w funkcji warunkowej IF. W jednej pobieram wartość za pomocą gettera, natomiast w drugiej odwołuję się do zmiennej wewnątrz klasy obiektu. Którego rozwiązania powinienem się trzymać? Które jest bardziej praktyczne i zgodne tzw. ze sztuką programowania?

Rozwiązanie nr 1:

List<Client> myClient = new ArrayList<>();

public class Client {
    private final String firstName;
    private final String lastName;
    protected String cID;
    protected boolean subscription = false;
}

public int getNumberOfSubsrtipion(){
    int count = 0;

    for( Client myCustomer: myClient ){
        if( myCustomer.subscription ){
            count += 1;
        }
    }

    return count;
}

Rozwiązanie nr 2:

List<Client> myClient = new ArrayList<>();

public class Client {
    private final String firstName;
    private final String lastName;
    protected String cID;
    private boolean subscription = false;

    protected boolean getSubscription(){
        return this.subscription;
    }
}

public int getNumberOfSubsrtipion(){
    int count = 0;

    for( Client myCustomer: myClient ){
        if( myCustomer.getSubscription() ){
            count += 1;
        }
    }

    return count;
}

Jako, że od niedawna uczę się programowania w Javie, to prosiłbym o kilka słów wytłumaczenia tego problemu.

Z góry dziękuję za pomoc.

Ogólnie konwencja jest taka, że dostęp do pól klasy z zewnątrz jest przez gettery/settery. Natomiast zrobiłbym to inaczej, czyli opcja nr. 3

public class Client {
    private final String firstName;
    private final String lastName;
    private String cID;
    private boolean subscribed = false;

    protected boolean isSubscribed() {
      return subscribed; 
    }
}

/// ...

public long getNumberOfSubsrtipion(List<Client> clients){
    return clients.stream()
      .filter(Client::isSubscribed)
      .count();
}

boolean isSubscribed() brzmi lepiej niż boolean getSubscription() - getSubscription() bardziej przypomina, że metoda powinna zwracać jakiś obiekt typu Subscription.

Tak na prawdę to wszystko jedno.

Tak / nie / zależy

Chyba najważniejszy punkt do refleksji, czy klasa jest mutowalna, czy niemutowalna.
Niemutowalne bardzo fajnie się implementuje z polami public final i bez getterów.

(Moja własna postawa: cenię, jak mam niemutowalne ale nie wypruwam sobie flaków jak gdzies mutowalna jest lepiej pasujaca)

Drugie zagadnienie nie dotyczy ortodoksji czy elegancji, a wydajności

Zgadzam się, że wszystko jedno.

Gettery i Settery to taki spadek z ery IDE łupanego, kiedy nie było dobrych debuggerów, refaktoringu. Wstawiało się breakpoint, albo print("dupa") w settera i już wiadomo, kto rusza.
Teraz to nie ma praktycznie sensu:
a) może ustawić breakpoint na zmianę pola,
b) można w IDE łatwo wyszukać gdzie pole jest używane (read i write),
c) można łatwo zamienić (w tych rzadkich przypadkach kiedy trzeba) pole na gettery i settery,

a co do stylu
d) najlepiej to mieć pola final (niemutowalnych typów) i nie zmieniać - takie pola jako public są bezpieczne i bezproblemowe,
e) pola protected są podejrzane, nie jest tak, że dziedziczenia się już nie używa zupełnie, ale używa się rzadko,
f) jak potrzebujesz prostej struktury danych, to używasz rekordów i tu też problem się rozwiązuje

jarekr000000 napisał(a):

Zgadzam się, że wszystko jedno.

Gettery i Settery to taki spadek z ery IDE łupanego, kiedy nie było dobrych debuggerów, refaktoringu. Wstawiało się breakpoint, albo print("dupa") w settera i już wiadomo, kto rusza.
Teraz to nie ma praktycznie sensu:
a) może ustawić breakpoint na zmianę pola,
b) można w IDE łatwo wyszukać gdzie pole jest używane (read i write),
c) można łatwo zamienić (w tych rzadkich przypadkach kiedy trzeba) pole na gettery i settery,

Jest jeszcze kwestia enkapsulacji i utrzymywania niezmiennego, zewnętrznego interface'u klasy.

a co do stylu
d) najlepiej to mieć pola final (niemutowalnych typów) i nie zmieniać - takie pola jako public są bezpieczne i bezproblemowe,

No i w takim przypadku gettery faktycznie stają się dyskusyjne.

e) pola protected są podejrzane, nie jest tak, że dziedziczenia się już nie używa zupełnie, ale używa się rzadko,

W dziedziczeniu, to jeszcze ujdzie metoda protected, ale pole to już grabie położone zębami na sztorc, prędzej, czy później ktoś je nadepnie, najczęściej ten, kto kładł.