02. Obiekty, klasy i zdarzenia czyli wspólnej podróży ciąg dalszy

Można kupić bilet, ale nie można kupić punktu w układzie współrzędnych.

Omówiona wcześniej funkcja zakupu biletu zwracała informacje o bilecie, a funkcja matematyczna, wartość liczbową współrzędnej y, dla danej współrzędnej x.

Grupowanie procedur i funkcji w moduły, określanie jakiego typu ma być każdy z podawanych parametrów i zwracanych wyników, rozwiązuje problem pomyłek w sposób, który dla programistów był wystarczający przez wiele lat.

Z czasem pojawił się pomysł grupowania informacji oraz procedur i funkcji, które na nich operują w odrębne obiekty.

W życiu codziennym, obiektem może być praktycznie wszystko: ziarnko piasku, krzesło, siedzący na nim człowiek, planeta, galaktyka, albo nawet wszechświat.

W programowaniu – podobnie: fragment tekstu w edytorze, paragraf, cały dokument, plik, folder, zawartość dysku, całego urządzenia, chmury danych…

Każdy obiekt posiada pewien zbiór atrybutów (dotyczących go informacji), oraz zbiór metod (procedur i funkcji), które na nim operują.

Dla przykładowego biletu, atrybutami byłyby m.in.:

  • Miejsce rozpoczęcia podróży,
  • miejsce zakończenia podróży,
  • środek transportu,
  • data i czas rozpoczęcia podróży,
  • data i czas zakończenia podróży.

Metodami natomiast mogłyby być:

  • Zarezerwuj,
  • dokonaj zakupu,
  • zmień dane podróżnego,
  • anuluj rezerwację,
  • wydrukuj.

W naszym oprogramowaniu mogłoby istnieć wiele biletów o różnych właściwościach, ale wspólnym zestawie operujących na nich metod.

Taki zestaw podobnych obiektów, to klasa.

Programista definiuje najpierw jakąś klasę obiektów (np. klasa bilety), określa jakie mają one mieć właściwości i metody, a następnie, po oprogramowaniu metod, może w aplikacji tworzyć obiekty danej klasy.

Bilet z Warszawy do Gdańska na 30 września, będzie pojedynczym obiektem klasy Bilety.

Dziedziczenie

Dziedziczenie klas, to kolejna ciekawa koncepcja.

Klasa Bilety, posiadała zdefiniowaną właściwość “Środek transportu”, czyli informację o tym, czy jest to bilet autobusowy, kolejowy, czy lotniczy.
Co jednak z obsługą specyfiki konkretnego typu biletów: bilet kolejowy mógłby posiadać informację o numerze wagonu i zarezerwowanego miejsca, dodawanie tych właściwości dla całej klasy Bilety nie miałoby jednak sensu.

Może więc utworzenie zupełnie nowej klasy “Bilety kolejowe”?
Też nie jest to dobry pomysł, gdyż wymagałby przepisania większości innych wspólnych dla biletów właściwości i metod.

Rozwiązaniem jest dziedziczenie, czyli możliwość definiowania jakiejś klasy na bazie innej, zdefiniowanej wcześniej.

A zatem moglibyśmy utworzyć klasę Bilety Kolejowe, dziedziczącą wszystkie właściwości i metody z klasy Bilety i definiującą kilka własnych, np. numer wagonu.

Na tej samej zasadzie moglibyśmy utworzyć klasę Bilety lotnicze, która zawierałaby wszystkie właściwości i metody klasy Bilety, rozszerzone o właściwości i metody specyficzne dla podróży lotniczych.

Zdarzenia

Wakacje zaplanowane, rezerwacja noclegów zrobiona, bilety kupione, a nagle wydarza się coś, co sprawia, że plany musimy anulować, bądź przesunąć.
W takim przypadku wszystkie kupione bilety, zrobione rezerwacje noclegów i muzeów, musielibyśmy po kolei anulować.

Co by jednak było, gdyby nasze bilety miały odrobinę swojej własnej inteligencji i dowiedziawszy się, że wakacje odwołane – same z siebie anulowały swoje rezerwacje?
Dla właściciela, na pewno duża oszczędność czasu i pamięci.

Podobnie rzecz się ma w oprogramowaniu.
W systemie ma miejsce całe mnóstwo zdarzeń m.in.:

  • użytkownik zmienił rozmiar okna,
  • użytkownik kliknął w którymś obszarze okna aplikacji,
  • bateria w urządzeniu przenośnym wyczerpuje się i system przechodzi w stan oszczędzania energii.

Aplikacja natomiast może składać się z dziesiątek, albo nawet setek różnych obiektów.
Działanie niektórych z nich może być uzależnione od jakichś zachodzących w systemie zdarzeń, np. konieczność zmiany ikonki na przycisku, który jest obiektem interfejsu, albo wykonania jakiejś akcji po kliknięciu na ten przycisk.

Gdyby każde zdarzenie powodowało odpytanie każdego istniejącego obiektu, czy jest tym zdarzeniem zainteresowany, opóźnienia aplikacji trwałyby bardzo długo.

Efektywniejszym podejściem jest możliwość rejestrowania przez obiekty obsługi jakichś zdarzeń, czyli zadeklarowanie przez obiekt, że ma być powiadamiany o zdarzeniu X, gdyż chce wówczas wykonać jakąś akcję.
Przenosząc ten mechanizm do naszego przykładu: obiekt bilet, a dokładniej – wszystkie obiekty klasy Bilety, deklarowałyby w momencie powstawania, że są zainteresowane zdarzeniami “Odwołanie wakacji”, oraz “Przesunięcie terminu wakacji”.
Obsługa tych zdarzeń polegałaby odpowiednio na anulowaniu rezerwacji bądź zakupu, albo zmianie terminu rezerwacji.

Obiektowy model dokumentu

Realizację wyżej opisanych idei, użytkownik codziennie napotyka w praktyce, uruchamiając przeglądarkę internetową.

  • Każda strona internetowa, to tzw. Document object model, czyli obiektowy model dokumentu.
  • Wszystkie elementy strony, takie jak fragmenty tekstu, paragrafy, linki, nagłówki, obrazki, to węzły dokumentu.
  • Wszystkie węzły to obiekty, mające wspólną pewną ilość atrybutów i metod.
  • Na wszystkich węzłach może zachodzić pewna ilość zdarzeń, również wspólnych z innymi węzłami (np. kliknięcie w jakiś węzeł).
  • Istnieją także atrybuty i zdarzenia specyficzne dla konkretnej klasy węzłów, np. dla list rozwijanych zdarzenie, gdy zmieniono obiekt zaznaczony na liście, a atrybut – indeks czyli numer zaznaczonego obiektu.
  • Częścią obiektowego modelu dokumentu jest oprogramowanie, które sprawia, że strona nie musi być statycznym, czyli niezmiennym dokumentem.
    Oprogramowanie to, napisane w języku JavaScript, ma pełny dostęp do węzłów dokumentu, może je zmieniać, dodawać, albo usuwać.
    To właśnie dzięki oprogramowaniu, przycisk “Odtwarzaj” może zmienić się na “Pauza”, gdy odtwarzanie się rozpoczęło.

JavaScript i programowanie w przeglądarce internetowej nie jest wolne od problemów dostępnościowych, więc w następnym odcinku nie tam napiszemy nasze pierwsze linie kodu.

12 komentarzy

  1. Pomysł z blogiem doskonały. Od razu się czuje potężność mózgów potężnych.
    Poproszę natomiast o odwrócenie kolejności wyświetlania komentarzy. To bardzo ułatwi podążanie za dyskusją.
    Powodzenia.

  2. Węzły są obiektami. A klasa węzłów Listy Rozwijane dziedziczy z klasy Węzły, czyli na obiekcie lista rozwijana można zrobić trochę tych samych operacji co na wszystkich węzłach, a też trochę specyficznych dla listy rozwijanej.

  3. Jak się mają węzły do dziedziczenia i klas? bo trochę to w sumie podobne jest. Tu i tam można tworzyć obiekty podobne do innych.

  4. Dobre pytanie: najpierw napiszemy poradnik, później postaramy się z nim dotrzeć pod strzechy i do szkół, a następnie zrobimy ankietę i statystykę.

  5. To teraz ciekawi mnie ile % osób by było w stanie się nauczyć programować na tyle, żeby chociaż z 50% błędów z czerwonej księgi rozwiązywać, powiedzmy jak by uczyć z waszego poradnika w pierwszej gimnazjum, czy tam w siódmej klasie na rozszerzonej informatyce.

  6. Czyli dobrze, że autorzy jeszcze w drugim odcinku się ze sobą zgadzają.
    Te dwa odcinki czysto teoretyczne były niezbędne, ale już w następnym przechodzimy do konkretów.

  7. Tak, ja tu się zgadzam i uważam, że wiedza na tym blogu zebrana pozwoli na bardzo dużo.
    Tylko warto wiedzieć, ile przeskoczyliśmy. Ja na przykład uważam, że w ten sposób powinno się uczyć programowania w szkołach: a ewentualne braki w teorii i podstawach uzupełniać potem. Bo tu od razu widać efekty, można coś robić, zamiast spędzać 3 miesiące na uczeniu się algorytmów sortujących i budowania drzew binarnych.

  8. Pajper, nie strasz. Gdybym ja, pisząc mój pierwszy program w 7 klasie podstawówki, który odgrywał przez głośniczek komputera kawałek "Dla Elizy" usłyszał taki tekst jak w twoim komencie, to pewnie ręce by mnie opadły i byłby to mój pierwszy i ostatni program tymi ręcami napisany.
    I oczywiście można się zastanawiać ile wiedzy mi brakuje do pełnej wiedzy, albo dołować, że jeszcze wiele wiedzy mi brakuje do pełnej wiedzy, ale to jest droga do nikąd.
    Zdecydowanie bardziej sensownie zastanowić się co chcę, lub mogę osiągnąć przy pomocy tej wiedzy i narzędzi, które aktualnie posiadam.
    Jeżeli mam wrażenie, że czegoś mi brakuje, albo coś dałoby się uprościć, to wtedy pod konkretne zadanie można konkretów sobie łatwo poszukać, albo dopytać w komentarzach.
    I wiadomo, że jak w każdej dziedzinie, tak też w programowaniu, uczenie się jest procesem ciągłym, ja miesiąc temu nie miałem pojęcia bladego o Rubym, a okazuje się, że to język podobny do innych, który też jak inne, ma swoje mocniejsze i słabsze strony…
    Cel, który mi przyświeca, na tym blogu, to pokazanie, że owiane mitologicznym nimbem tajemniczości pisanie oprogramowania, nie jest w rzeczywistości niczym nadludzko trudnym.
    Może ktoś się zaciekawi i zajmie się tym na poważnie i dołączy do zespołu redakcyjnego tego bloga.
    Może ktoś z czytelników tego bloga aktualnie w pierwszej gimnazjum pomyśli sobie, że no w sumie fajny ten Elten, ale on ma lepszy i ciekawszy pomysł…
    Ale byłbym usatysfakcjonowany zupełnie, gdyby jedna lub kilka osób zaczęła robić użytek z tej wiedzy do prostych zadań: piszę jakieś opowiadanko, chcę wylosować imiona bohaterów z listy wszystkich imion z rejestru Pesel; mam plik tekstowy, który chcę nietypowo posortować i usunąć duplikaty…

  9. Domyśliłem się tego, to akurat dobrze. Takie coś będzie można nawet reklamować, że elten profesjonalne blogi posiada i można tu dużo się ciekawych rzeczy nauczyć.

  10. Warto zauważyć, że na tym blogu skupiamy się na programowaniu obiektowym i języku Ruby, a więc przedstawiamy już konkretne, praktyczne rozwiązania.
    To dostatecznie wiele, by nauczyć was pisania nawet całkiem złożonych programów (np. do Eltena), ale jednak zrobiliśmy wielki skok nad programowaniem strukturalnym, pomijając sporo wyjaśnień tego, co, jak, dlaczego i po co. A więc skupiamy się tu na praktyce, ale jeśli kogoś ten blog pociągnie silniej w świat programowania i ktoś poczuje smykałkę do bycia programistą, będzie musiał sporo ponadrabiać we własnym zakresie.
    Naturalnie do drobnych poprawek, programów, przykładów czy propozycji z forum to w zupełności wystarczy. Ale jednak nie jest to wiedza pełna.
    Innymi słowy żywimy nadzieję, że po skończeniu poradnika damy wam dość wiedzy, by zrealizować 80 procent propozycji i poprawić 80 procent błędów zgłoszonych na forum… Ale do napisania Konferencji od zera to jedna będzie za mało. 🙂

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *