[Obiekty] Rozdział 1. Obiekty, projektowanie

Wprowadzenie

Robert L. Glass argumentował, że praktyka jest ważniejsza niż teoria. W szczególności rozwój oprogramowania jest dziedziną, w której praktyka wyprzedza teorię, a programiści uczą się najwięcej, gdy brudzą sobie ręce pisząc konkretny kod. Dlatego też, na chwilę odłóżmy teorię i koncepcje na bok i przyjrzyjmy się prostemu programowi.

Implementacja aplikacji do sprzedaży biletów

• Chcemy zorganizować małe wydarzenie promujące mały teatr.
  • Treść wydarzenia: Losowanie wśród widzów, którzy otrzymają bezpłatne zaproszenia na przedstawienie.
• Musimy rozdzielić widzów, którzy wygrali w losowaniu od tych, którzy nie wygrali.
  • Widzowie, którzy wygrali w losowaniu: wymieniają zaproszenie na bilet.
  • Widzowie, którzy nie wygrali w losowaniu: kupują bilet za pieniądze.

Kod przykładowy: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

Jaki jest problem?

Robert Martin opisuje trzy funkcje, które powinien spełniać moduł oprogramowania (bez względu na rozmiar, taki jak klasa, pakiet lub biblioteka, dowolny element składowy programu).

• Poprawne działanie w czasie wykonywania.
• Istnieje w celu zmian.
  • Zmiany powinny być możliwe do wykonania za pomocą prostych operacji.
• Komunikuje się z osobą czytającą kod.
  • Powinien być łatwy do odczytania i zrozumienia dla programisty.

Powyższa aplikacja do sprzedaży biletów spełnia pierwsze ograniczenie – poprawne działanie, ale nie spełnia celów zmiany i komunikacji.

Kod, który nie spełnia oczekiwań

Przyjrzyjmy się przyczynom braku spełnienia celu komunikacji.

• Co robi metoda enter() klasy Theater
  • Teatr otwiera torbę widza i sprawdza, czy jest w niej zaproszenie.
  • Jeśli w torbie jest zaproszenie, teatr każe kasjerowi przenieść bilet z kasy do torby widza.
  • Jeśli w torbie nie ma zaproszenia, teatr zabiera z torby widza gotówkę odpowiadającą cenie biletu, kupuje bilet i wkłada go do torby.
• Z punktu widzenia widza, teatr jako strona trzecia bezprawnie grzebie w jego torbie, zabiera pieniądze i wkłada do niej bilet.
• Z punktu widzenia kasjera, teatr jako strona trzecia bezprawnie manipuluje biletami i gotówką w kasie, bez jego zgody.
• Zrozumiały kod to taki, który nie odbiega znacząco od naszych oczekiwań, a zachowanie teatru odbiega od naszych oczekiwań.
  • Widz powinien sam wyjąć pieniądze z torby i zapłacić kasjerowi za bilet.
  • Kasjer powinien sam wyjąć bilet z kasy i przekazać go widzowi, a także przyjąć od niego pieniądze i włożyć je do kasy.
• Ponadto, aby zrozumieć metodę enter(), należy pamiętać o kilku szczegółach.
  • Widz posiada Torbę (Bag).
  • W torbie znajdują się pieniądze i bilet.
  • Kasjer sprzedaje bilety w Kasie Biletowej (TicketOffice), a w Kasie Biletowej przechowywane są pieniądze i bilety.

Kod podatny na zmiany

Metoda enter() zakłada dwa warunki.

• Widz zawsze nosi ze sobą torbę, w której przechowuje gotówkę i zaproszenie.
• Kasjer sprzedaje bilety tylko w kasie biletowej.

A co, jeśli sytuacja będzie inna?

• Widz może nie mieć torby.
• Widz może płacić kartą kredytową, a nie gotówką.
• Kasjer może sprzedawać bilety poza kasą biletową.

Na przykład, aby spełnić pierwszy warunek, musielibyśmy usunąć obiekt Bag klasy Audience i zmodyfikować powiązaną z nim metodę enter() klasy Theater. Dzieje się tak, ponieważ klasa Theater opiera się na zbyt szczegółowych informacjach, takich jak to, że widz musi mieć torbę, a kasjer sprzedaje bilety tylko w kasie biletowej. Jeśli którykolwiek z tych szczegółów ulegnie zmianie, będziemy musieli zmodyfikować zarówno tę klasę, jak i klasy od niej zależne (np. Theater).

Jest to problem związany z zależnościami między obiektami, a zależności te implikują wpływ na zmiany. Jednak projektowanie obiektowe ma na celu budowanie wspólnoty obiektów, które współpracują ze sobą i są od siebie zależne, więc nie chodzi o bezwzględne eliminowanie zależności, ale o utrzymanie minimalnej liczby zależnościi eliminowanie zbędnych zależności.

Przykładem nadmiernej zależności między obiektami jest wysokie sprzężenieIm wyższe sprzężenie między dwoma obiektami, tym większe prawdopodobieństwo, że będą one musiały być zmieniane razem. Dlatego celem projektowania jest obniżenie sprzężenia między obiektami, aby ułatwić zmiany.

Ulepszanie projektu

Teatr nie musi wiedzieć, czy widz ma torbę, ani czy kasjer sprzedaje bilety w kasie biletowej. Teatr chce po prostu, aby widz wszedł do teatru. Dlatego powinniśmy sprawić, aby widz samodzielnie zarządzał gotówką i zaproszeniem w swojej torbie, a kasjer samodzielnie zarządzał biletami i ceną sprzedaży w kasie biletowej, czyniąc je autonomicznymi jednostkami.

Zwiększanie autonomii

Obiekt, który wykonuje tylko ściśle powiązane zadania i deleguje niezwiązane zadania innym obiektom, nazywany jest obiektem o wysokiej spójności. Tworzenie autonomicznych obiektów, które samodzielnie zarządzają swoimi danymi, pozwala na obniżenie sprzężenia i zwiększenie spójności.

Programowanie proceduralne i obiektowe

• Programowanie proceduralne
  • Metoda enter() klasy Theater jest procesem, a Audience, TicketSeller, Bag, TicketOffice to dane.
  • Sposób umieszczania procesów i danych w osobnych modułach nazywany jest programowaniem proceduralnym.
  • Występuje wiele fragmentów kodu, które są sprzeczne z naszą intuicją. (np. Widz samodzielnie zarządza pieniędzmi i zaproszeniem).
  • Trudno jest ograniczyć wpływ zmian danych.
  • Zarządzanie odpowiedzialnością jest scentralizowane. (Teatr zarządza wszystkim).
• Programowanie obiektowe
  • Sposób umieszczania danych i procesów w tym samym module nazywany jest programowaniem obiektowym.
  • Możemy pisać kod zgodny z naszą intuicją.
  • Wpływ zmian danych można skutecznie ograniczyć dzięki inkapsulacji.
  • Każdy obiekt ponosi odpowiedzialność za siebie.
  • 
    

Kod przykładowy: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

Można to jeszcze ulepszyć.

• Klasa Bag klasy Audience nadal jest bierną jednostką, sterowaną przez klasę Audience, więc należy uczynić ją autonomicznym obiektem.
• TicketOffice klasy TicketSeller również jest kontrolowana przez TicketSeller. TicketOffice również powinno stać się autonomicznym obiektem.
  • Jednak po zmianie TicketOffice wykazuje zwiększone sprzężenie z Audience.
  • Projektowanie wymaga rozważenia kompromisów. W tym przypadku można uznać, że TicketOffice powinno być nieco biernym obiektem, aby obniżyć sprzężenie z Audience.

Kod przykładowy: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

To kłamstwo!

• W rzeczywistości, nawet jeśli coś jest bierne, to w świecie obiektowym wszystko staje się aktywne i autonomiczne.
• Dobrze jest używać personifikacji, wyobrażając sobie bierne obiekty jako coś, co się śmieje, gada i denerwuje.

Projektowanie obiektowe

Dlaczego projektowanie jest konieczne?

• Projektowanie to rozmieszczanie kodu.
• Dobry projekt to taki, który w pełni realizuje dzisiejsze wymagania funkcjonalne i jednocześnie pozwala na płynne wdrożenie przyszłych zmian.

Projektowanie obiektowe

• Zmieniający się kod to kod łatwy do zrozumienia.
• Paradygmat obiektowy pomaga pisać kod w sposób, w jaki postrzegamy świat.
• Obiekt jest autonomicznym bytem, który sam odpowiada za swoje dane.
• Doskonały projekt obiektowy to taki, który odpowiednio zarządza zależnościami między współpracującymi obiektami.

Źródła

• Obiekty