Metody korzystające z prywatnych członków lub publicznych akcesorów

Question

Zdaję sobie sprawę, że prawdopodobnie nie może być odpowiedział, ale szukam, czy istnieje jakiś poradnik o tym, czy używać prywatnych członków bezpośrednio lub publicznych dostęp do metod klasy.

Na przykład rozważmy następujący kod (w Javie, ale to będzie wyglądać bardzo podobnie w C++):

public class Matrix { 

    // Private Members 
    private int[][] e; 
    private int numRows; 
    private int numCols; 

    // Accessors 
    public int rows(){ return this.numRows; } 
    public int cols(){ return this.numCols; } 

    // Class Methods 
    // ... 
    public void printDimensions() 
    { 
     // [A] Using private members 
     System.out.format("Matrix[%d*%d]\n", this.numRows, this.numCols); 


     // [B] Using accessors 
     System.out.format("Matrix[%d*%d]\n", this.rows(), this.cols()); 
    } 

Funkcja printDimensions() przedstawia dwa sposoby, aby uzyskać tę samą informację, [A] przy pomocy członków prywatnych (this.numRows, this.numCols) lub [B] przez akcesory (this.rows(), this.cols()).

Z jednej strony możesz preferować używanie akcesorów, ponieważ nie ma możliwości nieumyślnej zmiany wartości prywatnych zmiennych składowych. Z drugiej strony możesz preferować bezpośredni dostęp do prywatnych użytkowników w nadziei, że usunie to niepotrzebne wywołanie funkcji.

Domyślam się, że moje pytanie jest, czy jest to standard de facto, czy preferowany?

Answer 1

To połączenie stylu. Wolę używać akcesorów, ponieważ IMHO, koszt wywołania funkcji jest na tyle mały, że w większości przypadków nie ma to znaczenia, a to użycie zachowuje abstrakcję danych. Jeśli później chcę zmienić sposób przechowywania danych, wystarczy zmienić akcesory, zamiast polować na wszystkie miejsca, w których dotknąłem zmiennych.

Nie mam jednak co do tego zdecydowania, i złamałbym tę "regułę", jeśli uważam, że mam ku temu dobry powód.

Answer 2

Mam inne obiekty, w tym podklas obiektu, użyj akcesorów, ale sam obiekt użyje pól. W ten sposób istnieje wyraźne rozróżnienie między elementami wewnętrznymi a interfejsem z resztą świata. Ukrywanie zawartości klasy od siebie wydaje się niepotrzebne i potencjalnie mylące. Jeśli coś naprawdę zyskuje na tym, że jego implementacja jest ukryta przed innymi częściami obiektu, podziel je na osobny obiekt.

Answer 3

IMHO, akcesory są bardziej kwestią struktury i zarządzania danymi niż akcesorów jako takich. Czasami, przed ich zwróceniem, należy przetworzyć niektóre dane. Pomyśl o tym przykładzie:

public class Foo { 

    private List<Bar> bars = null; 

    //Methods and stuff 

    public List<Bar> getBars() { 
     if(bars == null) 
      bars = SomeClass.loadBars(); 
      // You can also use 
      // setBars(SomeClass.loadBars()); 
     return bars; 
    } 

} 

W tym przypadku nie jest twoja rodzicielka tylko owijając swoje pole, ale wracając pole zainicjowanego w dowolnej chwili wywołać go. Używanie akcesorów wewnątrz klasy daje te same korzyści, które dla osób postronnych, wyodrębniasz się z konkretnych szczegółów pola i możesz je uzyskać po jego przetworzeniu.

Z drugiej strony, jeśli twoje pole jest zwracane bezpośrednio (powiedzmy, String), nie ma znaczenia, czy używasz get, czy nie, ale możesz chcieć użyć standardu Twój kod.

Ostatecznie wszystko sprowadza się do stylu kodowania.