Czy zawsze powinienem całkowicie zawierać wewnętrzną strukturę danych?

Proszę rozważyć tę klasę:

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThings(){
        return things;
    }

}

Ta klasa udostępnia tablicę, której używa do przechowywania danych, każdemu zainteresowanemu kodowi klienta.

Zrobiłem to w aplikacji, nad którą pracuję. Miałem ChordProgressionklasę, która przechowuje sekwencję Chords (i robi kilka innych rzeczy). Miał Chord[] getChords()metodę, która zwróciła tablicę akordów. Gdy struktura danych musiała się zmienić (z tablicy na ArrayList), cały kod klienta się zepsuł.

To sprawiło, że pomyślałem - może lepsze jest następujące podejście:

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThing(int index){
        return things[index];
    }

    public int getDataSize(){
        return things.length;
    }

    public void setThing(int index, Thing thing){
        things[index] = thing;
    }

}

Zamiast ujawniać samą strukturę danych, wszystkie operacje oferowane przez strukturę danych są teraz oferowane bezpośrednio przez klasę ją otaczającą, przy użyciu publicznych metod delegowanych do struktury danych.

Kiedy zmienia się struktura danych, tylko te metody muszą się zmienić - ale po tym, cały kod klienta nadal działa.

Należy pamiętać, że kolekcje bardziej złożone niż tablice mogą wymagać, aby klasa otaczająca zaimplementowała więcej niż trzy metody tylko w celu uzyskania dostępu do wewnętrznej struktury danych.

Czy to podejście jest powszechne? Co o tym sądzisz? Jakie wady ma inne? Czy rozsądne jest, aby klasa otaczająca implementowała co najmniej trzy metody publiczne tylko w celu delegowania do wewnętrznej struktury danych?

Kod jak:

   public Thing[] getThings(){
        return things;
    }

To nie ma większego sensu, ponieważ twoja metoda dostępu nie robi nic, tylko bezpośrednio zwraca wewnętrzną strukturę danych. Równie dobrze można po prostu zadeklarować Thing[] thingssię public. Ideą metody dostępu jest stworzenie interfejsu, który izoluje klientów od wewnętrznych zmian i uniemożliwia im manipulowanie rzeczywistą strukturą danych, z wyjątkiem dyskretnych sposobów, na jakie pozwala interfejs. Jak odkryłeś, kiedy cały kod klienta się zepsuł, twoja metoda dostępu tego nie zrobiła - to po prostu zmarnowany kod. Myślę, że wielu programistów ma tendencję do pisania takiego kodu, ponieważ dowiedzieli się gdzieś, że wszystko musi być otoczone metodami dostępu - ale to z powodów, które wyjaśniłem. Robienie tego tylko po to, by „podążać za formą”, gdy metoda dostępu nie służy żadnemu celowi, to po prostu hałas.

Zdecydowanie poleciłbym zaproponowane rozwiązanie, które realizuje niektóre z najważniejszych celów enkapsulacji: Zapewnienie klientom solidnego, dyskretnego interfejsu, który izoluje ich od wewnętrznych szczegółów implementacyjnych twojej klasy i nie pozwala im dotknąć wewnętrznej struktury danych oczekuj w sposób, który uznasz za odpowiedni - „prawo najmniej koniecznego przywileju”. Jeśli spojrzysz na duże popularne frameworki OOP, takie jak CLR, STL, VCL, zaproponowany przez ciebie wzorzec jest powszechny, właśnie z tego powodu.

Czy zawsze powinieneś to robić? Niekoniecznie. Na przykład, jeśli masz klasy pomocnika lub przyjaciela, które są zasadniczo składnikiem twojej głównej klasy robotniczej i nie są skierowane do przodu, nie jest to konieczne - to przesada, która doda wiele niepotrzebnego kodu. W takim przypadku w ogóle nie użyłbym metody dostępu - jak wyjaśniono - jest bez sensu. Po prostu zadeklaruj strukturę danych w sposób, który ogranicza się tylko do głównej klasy, która z niej korzysta - większość języków obsługuje takie sposoby - friendlub deklarując ją w tym samym pliku, co główna klasa robotnicza itp.

Jedynym minusem, jaki widzę w twojej propozycji, jest to, że kodowanie wymaga więcej pracy (a teraz będziesz musiał ponownie kodować swoje klasy konsumenckie - ale i tak musiałeś / musiałeś to zrobić). Ale to nie jest tak naprawdę wada - musisz to zrobić dobrze, a czasem wymaga to więcej pracy.

Jedną z rzeczy, które sprawiają, że dobry programista jest dobry, jest to, że wiedzą, kiedy dodatkowa praca jest tego warta, a kiedy nie. W dłuższej perspektywie wprowadzenie dodatkowej kwoty w przyszłości przyniesie duże dywidendy - jeśli nie na tym projekcie, to na innych. Naucz się kodować we właściwy sposób i używaj do tego swojej głowy, a nie tylko automatycznie wykonuj określone formularze.

Należy pamiętać, że kolekcje bardziej złożone niż tablice mogą wymagać, aby klasa otaczająca zaimplementowała więcej niż trzy metody tylko w celu uzyskania dostępu do wewnętrznej struktury danych.

Jeśli ujawniasz całą strukturę danych za pośrednictwem zawierającej klasy, IMO musisz pomyśleć, dlaczego ta klasa jest w ogóle enkapsulowana, jeśli nie chodzi tylko o zapewnienie bezpieczniejszego interfejsu - „klasy opakowania”. Mówisz, że klasa zawierająca nie istnieje w tym celu - więc być może coś jest nie tak z twoim projektem. Zastanów się nad podziałem swoich klas na bardziej dyskretne moduły i warstwowaniem ich.

Klasa powinna mieć jeden jasny i dyskretny cel oraz zapewniać interfejs do obsługi tej funkcjonalności - nie więcej. Być może próbujesz połączyć ze sobą rzeczy, które do siebie nie pasują. Gdy to zrobisz, wszystko się zepsuje za każdym razem, gdy będziesz musiał wprowadzić zmianę. Im mniejsze i bardziej dyskretne są twoje zajęcia, tym łatwiej jest to zmieniać: Pomyśl LEGO.

Pytanie: Czy zawsze powinienem całkowicie zawierać wewnętrzną strukturę danych?

Krótka odpowiedź: Tak, przez większość czasu, ale nie zawsze .

Długa odpowiedź: Myślę, że klasy dzielą się na następujące kategorie:

1. Klasy, które zawierają proste dane. Przykład: punkt 2D. Łatwo jest tworzyć funkcje publiczne, które umożliwiają uzyskanie / ustawienie współrzędnych X i Y, ale można łatwo ukryć dane wewnętrzne bez większych problemów. W przypadku takich klas ujawnianie szczegółów wewnętrznej struktury danych jest nieuzasadnione.

2. Klasy kontenerów, które hermetyzują kolekcje. STL ma klasyczne klasy kontenerów. Rozważam std::stringi std::wstringwśród nich też. Zapewniają bogaty interfejs do czynienia z abstrakcjami, ale std::vector, std::stringi std::wstringrównież dają możliwość, aby uzyskać dostęp do surowych danych. Nie spieszyłbym się z nazwaniem ich źle zaprojektowanymi zajęciami. Nie znam uzasadnienia dla tych klas, które ujawniają swoje surowe dane. Jednak w mojej pracy uznałem za konieczne ujawnienie surowych danych w kontaktach z milionami węzłów siatki i danych w tych węzłach siatki ze względu na wydajność.

   Ważną rzeczą w ujawnieniu wewnętrznej struktury klasy jest to, że musisz długo i intensywnie myśleć, zanim nadasz jej zielony sygnał. Jeśli interfejs jest wewnętrzny projektu, jego zmiana w przyszłości będzie kosztowna, ale nie niemożliwa. Jeśli interfejs jest zewnętrzny dla projektu (na przykład podczas opracowywania biblioteki, która będzie używana przez innych programistów aplikacji), zmiana interfejsu bez utraty klientów może być niemożliwa.

3. Klasy, które mają głównie charakter funkcjonalny. Przykłady: std::istream, std::ostream, iteratory pojemników STL. Głupotą jest ujawnianie wewnętrznych szczegółów tych klas.

4. Klasy hybrydowe. Są to klasy, które zawierają pewną strukturę danych, ale także zapewniają funkcjonalność algorytmiczną. Osobiście uważam, że są one wynikiem źle przemyślanego projektu. Jednak jeśli je znajdziesz, musisz zdecydować, czy sensowne jest ujawnianie ich wewnętrznych danych w poszczególnych przypadkach.

Podsumowując: Jedyny raz, kiedy uznałem za konieczne ujawnienie wewnętrznej struktury danych klasy, jest moment, w którym stała się ona wąskim gardłem wydajności.

Zamiast zwracać bezpośrednio surowe dane, spróbuj czegoś takiego

class ClassA {
  private Things[] things;
  ...
  public Things[] asArray() { return things; }
  public List<Thing> asList() { ... }
  ...
}

Zasadniczo zapewniasz niestandardową kolekcję, która przedstawia pożądaną twarz świata. W nowej implementacji

class ClassA {
  private List<Thing> things;
  ...
  public Things[] asArray() { return things.asArray(); }
  public List<Thing> asList() { return things; }
  ...
}

Teraz masz odpowiednią enkapsulację, ukrywasz szczegóły implementacji i zapewniasz wsteczną kompatybilność (za opłatą).

Powinieneś używać interfejsów do tych rzeczy. Nie pomogłoby to w twoim przypadku, ponieważ tablica Java nie implementuje tych interfejsów, ale powinieneś to zrobić od teraz:

class ClassA{

    public ClassA(){
        things = new ArrayList<Thing>();
    }

    private List<Thing> things; // stores data

    // stuff omitted

    public List<Thing> getThings(){
        return things;
    }

}

W ten sposób możesz zmienić ArrayListna LinkedListlub cokolwiek innego, i nie złamiesz żadnego kodu, ponieważ wszystkie kolekcje Java (oprócz tablic), które mają (pseudo?) Losowy dostęp, prawdopodobnie zostaną zaimplementowane List.

Możesz również użyć Collection, które oferują mniej metod niż, Listale mogą obsługiwać kolekcje bez losowego dostępu, lub Iterablektóre mogą nawet obsługiwać strumienie, ale nie oferują wiele pod względem metod dostępu ...

Jest to dość częste ukrywanie wewnętrznej struktury danych przed światem zewnętrznym. Czasami jest to przesada, szczególnie w DTO. Polecam to dla modelu domeny. Jeśli w ogóle wymagane jest ujawnienie, zwróć niezmienną kopię. Wraz z tym sugeruję utworzenie interfejsu zawierającego takie metody jak get, set, remove itp.