To jest post przetłumaczony przez AI.
Wybierz język
Tekst podsumowany przez sztuczną inteligencję durumis
- W rozwoju oprogramowania praktyka jest ważniejsza niż teoria, a prosty program pozwala zrozumieć znaczenie obiektowego projektowania.
- Na przykładzie aplikacji do sprzedaży biletów opisano, jak pisać elastyczny kod poprzez zmniejszenie zależności i sprzężenia między obiektami, a także porównano różnice między programowaniem proceduralnym a obiektowym.
- Obiektowe projektowanie tworzy kod, który można modyfikować, a obiekty są autonomicznymi bytami, które same odpowiadają za dane, a zarządzanie zależnościami między współpracującymi obiektami powinno być odpowiednie.
Wprowadzenie
Robert L. Glass argumentował, że praktyka jest ważniejsza niż teoria. W szczególności rozwój oprogramowania jest doskonałym przykładem tego, gdzie praktyka wyprzedza teorię, a programiści uczą się najwięcej, gdy brudzą sobie ręce, tworząc konkretny kod. Dlatego też teoria i koncepcje zostaną na chwilę odłożone na bok, aby przyjrzeć się prostym programom.
Implementacja aplikacji sprzedaży biletów
- Planowane jest zorganizowanie małego wydarzenia w celu promocji małego teatru.
- Treść wydarzenia: Losowanie wśród widzów, którzy otrzymają bezpłatne zaproszenia na spektakl
- Konieczne jest rozdzielenie widzów, którzy wygrali w losowaniu, od tych, którzy nie wygrali.
- Widzowie, którzy wygrali w losowaniu: Wymiana zaproszenia na bilet
- Widzowie, którzy przegrali w losowaniu: Zakup biletów za gotówkę
Jaki jest problem?
Robert Martin opisuje trzy funkcje, które powinien mieć moduł oprogramowania (bez względu na rozmiar, taki jak klasa, pakiet, biblioteka lub dowolny element składający się na program).
- Działa prawidłowo podczas wykonywania.
- Istnieje w celu zmian.
- Zmiany powinny być możliwe przy minimalnym wysiłku.
- Komunikuje się z osobami czytającymi kod.
- Programiści powinni być w stanie łatwo czytać i rozumieć kod.
Powyższa aplikacja sprzedaży biletów spełnia pierwsze ograniczenie, czyli prawidłowe działanie, ale nie spełnia celów zmiany i komunikacji.
Kod, który nie spełnia oczekiwań
Spójrzmy na powód, dla którego nie spełnia celu komunikacji.
- Co robi metoda enter() klasy Theater?
- Teatr sprawdza, czy w torbie widza znajduje się zaproszenie.
- Jeśli w torbie widza znajduje się zaproszenie, teatr prosi sprzedawcę o przeniesienie biletu przechowywanego w kasie do torby widza.
- Jeśli w torbie widza nie ma zaproszenia, teatr zabiera z torby widza tyle gotówki, ile kosztuje bilet, kupuje bilet i wkłada go do torby.
- Z punktu widzenia widza, teatr jako strona trzecia niepotrzebnie grzebie w jego torbie, zabiera pieniądze i wkładają bilet.
- Z punktu widzenia sprzedawcy, teatr jako strona trzecia niepotrzebnie manipuluje biletami i pieniędzmi w kasie bez pozwolenia.
- Zrozumiały kod to kod, którego działanie nie odbiega znacząco od naszych oczekiwań, a teatr wykracza poza nasze oczekiwania.
- Widz powinien samodzielnie wyciągnąć pieniądze z torby i zapłacić sprzedawcy za bilet.
- Sprzedawca powinien samodzielnie wyciągnąć bilet z kasy i przekazać go widzowi, a następnie odebrać od niego pieniądze i przechować je w kasie.
- Aby zrozumieć metodę enter(), należy pamiętać o wielu szczegółach.
- Audience ma Bag.
- W Bag znajdują się pieniądze i bilet.
- TiketSellet sprzedaje bilety w TicketOffice, a TicketOffice przechowuje pieniądze i bilety.
Kod podatny na zmiany
Metoda enter() zakłada dwa warunki.
- Widz zawsze nosi ze sobą torbę, aby przechowywać pieniądze i zaproszenie.
- Sprzedawca sprzedaje bilety tylko w kasie.
A co, jeśli:
- Widz może nie mieć torby.
- Widz może płacić kartą kredytową zamiast gotówki.
- Sprzedawca może sprzedawać bilety poza kasą.
Na przykład, aby spełnić pierwszy wymóg, należy usunąć obiekt Bag klasy Audience i zmodyfikować metodę enter() klasy Theater. Dzieje się tak ponieważ klasa Theater jest nadmiernie uzależniona od faktu, że widz nosi ze sobą torbę, a sprzedawca sprzedaje bilety tylko w kasie. Jeśli którykolwiek z tych szczegółów ulegnie zmianie, konieczna będzie modyfikacja zarówno tej klasy, jak i klas od niej zależnych (np. Theater).
Jest to problem związany z zależnością między obiektami, a zależność ta sugeruje wpływ na zmiany. Jednak projektowanie obiektowe ma na celu utworzenie społeczności obiektów współpracujących ze sobą i wzajemnie od siebie zależnych, dlatego nie chodzi o całkowite usunięcie zależności, ale o zachowanieminimalnej ilości zależnościniezbędnych do realizacji funkcji aplikacji i usunięcie zbędnych zależności.
Jeśli istnieje zbyt wiele zależności między obiektami, mówimy o wysokiej łącznościIm wyższa łączność między dwoma obiektami, tym większe prawdopodobieństwo, że będą one zmieniane razem. Zatem celem projektu jest zmniejszenie łączności między obiektami w celu stworzenia projektu łatwego w modyfikacji.
Poprawa projektu
Teatr nie musi wiedzieć, czy widz ma torbę, czy sprzedawca sprzedaje bilety w kasie. Teatr po prostu chce, aby widz wszedł do teatru. Dlatego widz powinien samodzielnie zarządzać pieniędzmi i zaproszeniem w torbie, a sprzedawca powinien samodzielnie zarządzać biletami i cenami biletów w kasie.
Zwiększenie autonomii
Obiekt, który wykonuje tylko ściśle powiązane zadania, a zadania niezwiązane z nim deleguje innym obiektom, nazywamy obiektem o wysokiej spójności. Tworzenie autonomicznych obiektów, które samodzielnie zarządzają swoimi danymi, pozwala na zmniejszenie łączności i zwiększenie spójności.
Programowanie proceduralne i obiektowe
- Programowanie proceduralne
- Metoda enter() klasy Theater to proces, a Audience, TicketSeller, Bag, TicketOffice to dane.
- Programowanie proceduralne to umieszczanie procesów i danych w oddzielnych modułach.
- Istnieje wiele kodów sprzecznych 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 (Theater zarządza wszystkim).
- Programowanie obiektowe
- Programowanie obiektowe to umieszczanie danych i procesów w tym samym module.
- Możliwość pisania kodu zgodnego z naszą intuicją.
- Możliwość skutecznego ograniczenia wpływu zmian danych dzięki kapsułkowaniu.
- Każdy obiekt jest odpowiedzialny za siebie.
Można go jeszcze poprawić.
- Klasa Bag klasy Audience nadal jest pasywnym elementem sterowanym przez klasę Audience, dlatego należy stworzyć klasę Bag jako autonomiczny obiekt.
- TicketOffice klasy TicketSeller jest również sterowane przez TicketSeller. TicketOffice należy stworzyć jako autonomiczny obiekt.
- Jednak po zmianie TicketOffice ma dodatkową łączność z Audience.
- Projektowanie polega na rozsądnym podejściu do kompromisów. W tym przypadku można uzgodnić, że TicketOffice będzie w pewnym stopniu obiektem pasywnym, aby zmniejszyć łączność z Audience.
Tak, to kłamstwo!
- Nawet jeśli w rzeczywistości coś jest pasywne, w świecie obiektowym wszystko staje się aktywne i autonomiczne.
- Dobrze jest używać personifikacji, aby traktować obiekty pasywne tak, jakby się śmiały, rozmawiały i złościły.
Projektowanie obiektowe
Dlaczego projektowanie jest konieczne?
- Projektowanie to umieszczanie kodu.
- Dobry projekt to taki, który w pełni realizuje dzisiejsze potrzeby, a jednocześnie bezproblemowo dostosowuje się do jutrzejszych zmian.
Projektowanie obiektowe
- Zmienne kody są łatwe do zrozumienia.
- Paradygmat obiektowy pozwala na tworzenie kodu w sposób zgodny z naszym spojrzeniem na świat.
- Obiekt jest autonomicznym bytem odpowiedzialnym za swoje dane.
- Doskonałe projektowanie obiektowe to zarządzanie zależnościami między współpracującymi obiektami.
Źródło
- Obiekty
