Czy jest to dobra praktyka kodowania do używania gettera do uzyskiwania dostępu do prywatnych zmiennych instancji

Question

Niedawno otrzymałem komentarz dotyczący sprawdzania kodu, aby użyć metody getter do uzyskiwania dostępu do prywatnej instancji zmiennej wewnątrz metod tej samej klasy. Czy to naprawdę dobra praktyka? Uważam, że dodaje niepotrzebne komplikacje w kodzie. Jaki jest zalecany sposób?

public class SomeClass { 
    String abc; 

    public boolean compare(SomeClass otherClass) { 
     otherClass.getAbc().equals(abc); 
    } 
} 

public class SomeClass { 
    String abc; 

    public boolean compare(SomeClass otherClass) { 
     otherClass.getAbc().equals(getAbc()); 
    } 
} 

Answer 1

Widzę bardzo specyficzny problem z twoim pierwszym podejściem. Używasz niekonsekwentnie modułów pobierających.

public boolean compare(SomeClass otherClass) { 
    otherClass.getAbc().equals(abc); 
    //.getAbc() for one, but direct access for the other!! 
} 

Trzeba porównać jabłka do jabłek dla równości metodę, a jeśli jeden z twoich zmiennych są pobierane dla porównania przy użyciu getter (które zakładam, że jest publiczny i może być zmienione), a drugi jest pobierany bezpośrednio z zmienna prywatna (której nie można przesłonić), wtedy Twój kod jest znacznie bardziej delikatny, niż powinien. Co jeśli ktoś rozszerzy twoją klasę i zmieni metodę gettera? Twój kod zostanie zablokowany. Dlatego użyj gettera na obu lub żaden.

Mając to na uwadze, jeden z nich jest lepszy od oryginału, ponieważ zachowanie jest bardziej stabilny:

public boolean compare(SomeClass otherClass) { 
    otherClass.abc.equals(abc); 
} 


public boolean compare(SomeClass otherClass) { 
    otherClass.getAbc().equals(getAbc()); 
} 

Dla celów ogólnych, to zależy od tego jak używasz danych. Odpowiedź Davida zawiera listę zasobów do ogólnego wykorzystania modułów pobierających.

Jest całkiem możliwe, że Twój recenzent mówił tylko o ogólnym przypadku, ale myślę, że po prostu źle zakomunikowali problem.

Answer 2

Teoretycznie używanie metod pobierających i ustawiających w klasie może zapewnić ponowne użycie kodu, na przykład, jeśli ustawiający dokonuje pewnego rodzaju sprawdzania zakresu, co jest przydatne również w klasie. W praktyce nigdy nie widziałem przypadku, w którym było to naprawdę korzystne.

Idealnie klasa nie powinna w ogóle mieć seterów i pobierających.

Dlaczego nie seterów? Ponieważ zapewniają one zmienny stan, który powoduje wiele problemów. Zmienne klas powinny być idealnie przypisane do konstruktora i nigdy później nie zmieniać.

Dlaczego nie pobiera się? Ponieważ klasa powinna działać jako jednostka. Celem stworzenia klasy jest nie tylko zapewnienie tymczasowego kontenera dla różnych zmiennych, aby później je wyodrębnić, jeden po drugim. To nie jest enkapsulacja.