Gettery/Settery. Zło. I okres

Artykuł Egora Bugaenko 19 września 2014 r. | Opublikowane w: Core Java Ta stara debata została zapoczątkowana przez Allena Holuba w jego słynnym artykule z 2003 roku: Dlaczego metody pobierające i ustawiające są złe - czy metody pobierające/ustawiające są anty-wzorem i czy powinniśmy ich unikać, czy też jest to coś, czego powinniśmy unikać? potrzebne w programowaniu obiektowym. Dorzucę swoje trzy grosze do tej dyskusji. Istota poniższego tekstu jest następująca: metody pobierające i ustawiające to zła praktyka; ci, którzy ich używają, nie mają żadnego usprawiedliwienia. Ale znowu, aby uniknąć nieporozumień, wcale nie sugeruję, że tam, gdzie to możliwe, należy unikać stosowania get/set. NIE. Mówię, że nawet nie pozwoliłeś im zbliżyć się do swojego kodu . Co sądzisz o tym stwierdzeniu? Godny Twojej uwagi? Czy używasz wzorca get/set od 15 lat i jesteś szanowanym architektem Java? A ty nawet nie chcesz słuchać tych bzdur od nieznajomego? Cóż... rozumiem Twoje uczucia. Poczułem to samo, dopóki nie natknąłem się na książkę Davida Westa „Object Thinking” - jest to najlepsza książka o programowaniu obiektowym, jaką kiedykolwiek czytałem. Więc proszę. Uspokój się i spróbuj zrozumieć, co próbuję wyjaśnić. Przedmiot kontrowersji Istnieje kilka argumentów przeciwko „akcesorom” (inna nazwa metod pobierających i ustawiających) w świecie obiektowym. I wszystkie są to bardzo trafne argumenty. Rzućmy na nie okiem. Pytaj, nie mów : Allen Holub mówi: „Nie proś o informacje potrzebne do wykonania pracy; «poproś» podmiot posiadający te informacje, aby wykonał tę pracę za Ciebie”. Naruszona zasada enkapsulacji : obiekt może zostać rozebrany przez inne obiekty, ponieważ są one w stanie osadzić w obiekcie dowolne dane za pomocą metod ustawiających. Obiekt po prostu nie może wystarczająco bezpiecznie hermetyzować własnego stanu, ponieważ każdy może zmienić ten stan. Ujawniono szczegóły implementacji : Jeśli można uzyskać jeden obiekt z innego obiektu, oznacza to, że za bardzo polegamy na szczegółach implementacji pierwszego obiektu. Jeśli jutro to się zmieni (na przykład typ wyniku), będziemy musieli zmienić kod. Wszystkie powyższe uzasadnienia z pewnością mają sens, ale pomija to najważniejszy punkt. Podstawowe błędne przekonanie Większość programistów uważa, że ​​obiekt jest strukturą danych zawierającą metody. Cytuję artykuł Bozhidara Bozhanova: Gettery i Settery nie są złe. Jednak większość obiektów, dla których tworzone są moduły pobierające i ustawiające, zawiera po prostu dane. To błędne przekonanie jest wynikiem ogromnego nieporozumienia! Obiekty nie „tylko przechowują dane”. Obiekty nie są strukturami danych z dołączonymi metodami. Ta koncepcja „przechowywania danych” wywodzi się z języków programowania obiektowego i języków proceduralnych, zwłaszcza C i COBOL. Powtórzę jeszcze raz: obiekt to nie tylko zbiór elementów danych i funkcji, które nimi manipulują. Obiekt nie jest obiektem danych. Co wtedy? Piłka i pies W prawdziwym programowaniu obiektowym obiekty są żywymi istotami, takimi jak ty i ja. Są to żywe organizmy, posiadające własne zachowanie, właściwości i cykl życiowy. Czy żywy organizm może mieć setera? Czy można przyczepić („ustawić”) piłkę psu? Nie myśl. Ale właśnie to robi poniższy fragment kodu:

Dog dog = new Dog();
dog.setBall(new Ball());

Jak ci się podoba? Czy potrafisz wyciągnąć („wyciągnąć”) piłkę z psa? Cóż, załóżmy, że możesz. Na wypadek, gdyby to zjadła, a ty przeprowadziłeś na niej operację. W tym przypadku tak, będziesz mógł odebrać („zdobyć”) piłkę psu. Właśnie o tym mówię:

Dog dog = new Dog();
Ball ball = dog.getBall();

Albo jeszcze bardziej absurdalny przykład:

Dog dog = new Dog();
dog.setWeight("23kg");

Czy możesz sobie to wyobrazić w prawdziwym życiu? Czy to brzmi tak, jakbyś pisał codziennie? Jeśli tak, to jesteś programistą proceduralnym. Po prostu przyznaj to. Oto, co David West mówi na stronie 30 swojej książki: Pierwszym krokiem w przekształceniu odnoszącego sukcesy programisty proceduralnego w odnoszącego sukcesy programistę obiektywnego jest lobotomia. Czy potrzebujesz lobotomii? Zdecydowanie tego potrzebowałem i zdobyłem go czytając książkę Westa „Myślenie obiektowe”. Myślenie Obiektywne Zacznij myśleć jak przedmiot, a natychmiast zmienisz nazwy tych metod. Oto, co możesz otrzymać:

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

Teraz traktujemy psa jak prawdziwe zwierzę, które może nam odebrać piłkę i oddać, jeśli o to poprosimy. Na wszelki wypadek zauważam, że pies nie może zwrócić NULL. Psy po prostu nie wiedzą, co to jest NULL! Obiektywne myślenie (myślenie) natychmiast usuwa odniesienia NULL z Twojego kodu. Ryba zwana Wandą (1988) Charlesa Crichtona Dodatkowo obiektywne myślenie doprowadzi do niezmienności obiektu, takiego jak w naszym przykładzie „waga psa”. Przepisałbyś kod mniej więcej tak:

Dog dog = new Dog("23kg");
int weight = dog.weight();

Pies to niezmienny żywy organizm, który nie pozwoli nikomu z zewnątrz zmienić swojej wagi, rozmiaru, imienia itp. Na życzenie może „powiedzieć” swoją wagę lub imię. Nie ma nic złego w metodach publicznych, które ujawniają zapytania dotyczące pewnych „wewnętrznych” właściwości obiektu. Metody te nie są jednak metodami pobierającymi i nigdy nie powinny otrzymywać przedrostka „get”. Nie „wychodzimy” z psa. Nie rozumiemy jej imienia. Prosimy ją, aby podała nam swoje imię. Czy widzisz różnicę? Nie mówimy tu nawet o semantyce. Rozróżniamy proceduralne podejście do programowania od obiektowego. W programowaniu proceduralnym pracujemy z danymi, manipulujemy nimi, pobieramy je, ustawiamy i, jeśli to konieczne, usuwamy. My rządzimy, a dane to tylko element pasywny. Pies jest dla nas niczym – po prostu „zawiera dane”. Ona nie ma własnego życia. Możemy z niego swobodnie wydobyć (uzyskać) wszystko, czego potrzebujemy i umieścić (ustawić) w nim dowolne dane. Tak działają (działały) C, COBOL, Pascal i inne języki proceduralne. Natomiast sytuacja jest zupełnie odwrotna w świecie obiektowym. Tutaj traktujemy przedmioty jak żywe organizmy, posiadające własną datę urodzenia i moment śmierci, własną osobowość i nawyki, jeśli kto woli. Możemy poprosić psa o podanie nam danych (np. wagi), a on nam te informacje zwróci. Ale zawsze pamiętaj, że pies jest aktywnym składnikiem. Ona decyduje, co się stanie po złożeniu wniosku. I dlatego absolutnie niewłaściwe jest, aby metody obiektu zaczynały się od set lub get. I nie chodzi tu nawet o naruszenie enkapsulacji, jak wielu osobom się wydaje. Chodzi o to, że albo myślisz jak obiekt, albo nadal piszesz w języku COBOL ze składnią Java. PS . I tak, możesz zapytać: „A co z JavaBeans, JPA, JAXB i wieloma innymi interfejsami API Java zależnymi od get/set?” A co z wbudowaną funkcją w Ruby, która ułatwia tworzenie akcesorów? Cóż mogę ci powiedzieć... nie masz szczęścia. O wiele łatwiej jest pozostać w prymitywnym świecie proceduralnego COBOL-a, niż zrozumieć i ogarnąć wspaniały świat rzeczywistych obiektów. P.P.S. _ Zapomniałem powiedzieć, że tak, wstawianie zależności za pomocą setera jest również okropnym anty-wzorem. Ale o tym więcej w następnym poście! Oryginalny artykuł