Co to jest programowanie obiektowe?
Programowanie obiektowe to określone podejście do programowania. Opiera się na idei grupowania powiązanych danych i funkcji w „wyspy” informacji. Te wyspy nazywa się obiektami.
Niezależnie od tego, z jakiego podejścia korzystasz, w programach stosowana jest taka sama seria kroków rozwiązywania problemów:
- Dane wejściowe: dane są odczytywane z miejsca, które mogą być magazynem danych, takimi jak system plików lub baza danych.
- Przetwarzanie: dane są interpretowane i ewentualnie zmieniane do przygotowania do wyświetlania.
- Dane wyjściowe: dane są prezentowane w taki sposób, aby można je było odczytywać i wchodzić w interakcje z użytkownikiem fizycznym lub systemem.
Programowanie obiektowe a proceduralne
Spróbujmy zdefiniować programowanie obiektowe przez porównanie go z innym podejściem: programowaniem proceduralnym. Programowanie proceduralne określa rozwiązanie danego problemu przez wywoływanie procedur, nazywanych również funkcjami lub metodami. W celu obsługi poszczególnych faz odpowiadających opisanym poprzednio krokom konstruowane są funkcje i zmienne.
W tym aspekcie programowanie obiektowe niczym się nie różni. Wyróżnia je natomiast sposób widzenia świata. W porównaniu z programowaniem proceduralnym programowanie obiektowe przyjmuje szerszą perspektywę. Zamiast pracować z danymi i przekazywać je z jednego etapu do następnego, w programowaniu obiektowym próbuje się zrozumieć świat, w jakim działają te dane. W tym celu konieczne jest modelowanie tego, co widzimy.
Modelowanie programowania obiektowego: identyfikowanie pojęć
Na etapie modelowania należy przyjrzeć się opisowi domeny i spróbować przeanalizować tekst dotyczący tego, co się dzieje. Pierwszym krokiem jest zidentyfikowanie aktorów. Pewne elementy są nazywane aktorami, ponieważ działają i wykonują akcje. Na przykład drukarka (aktor) drukuje (wykonuje akcję).
Po zidentyfikowaniu aktorów przyjrzysz się temu, co robią, co to jest ich zachowanie. Następnie należy przyjrzeć się opisom aktorów i zastanowić się, jakie dane są im potrzebne do wykonania akcji. Aktorzy stają się obiektami, ich cechy są kodowane jako dane w ramach obiektów, a zachowania stają się funkcjami dodanymi do obiektu.
Założenie jest takie, że dane w obiektach można zmieniać, wywołując funkcje względem tych obiektów. Ponadto obiekty mogą wchodzić ze sobą nawzajem w interakcje, aby osiągnąć konkretny wynik.
Zalety programowania obiektowego
Dlaczego więc warto korzystać z programowania obiektowego? Dlaczego by nie wybrać innego podejścia? Dla jasności należy podkreślić, że programowanie obiektowe nie jest ani gorsze, ani lepsze niż inne podejścia. Każde z nich ma swoje wady i zalety. Programowanie obiektowe ma pewne ładne korzyści, na przykład:
- Hermetyzacja danych: Hermetyzacja danych polega na ukrywaniu danych z dala od reszty systemu i zezwalaniu tylko na dostęp do ich części. Jest to wskazane, ponieważ dane mają stan, który może składać się z jednej zmiennej bądź z wielu. Jeśli te zmienne trzeba zmienić jednocześnie, muszą być chronione, a dostęp powinien być możliwy tylko za pośrednictwem metod publicznych, tak aby zmiany odbywały się w sposób przewidywalny. Programowanie obiektowe udostępnia mechanizmy takie jak poziomy dostępu, dzięki którym można określić, czy dostęp do danych w obiekcie może uzyskać tylko ten obiekt, czy też będą one dostępne publicznie.
- Prostota: Tworzenie dużych systemów to złożone zadanie, z wieloma problemami do rozwiązania. Możliwość podzielenia złożonego zadania na mniejsze problemy — obiekty — oznacza, że całe to zadanie można uprościć.
- Łatwe modyfikowanie: w przypadku polegania na obiektach i modelowaniu systemu za ich pomocą łatwiej jest śledzić, jakie części systemu wymagają modyfikacji. Może to dotyczyć na przykład potrzeby poprawienia usterki lub dodania nowej funkcji.
- Łatwość konserwacji: utrzymywanie kodu w ogóle jest trudne i staje się coraz trudniejsze w czasie. Wymaga dyscypliny w formie dobrego nazewnictwa oraz jasnej i spójnej architektury, między innymi. Dzięki obiektom łatwiej znaleźć w kodzie konkretny obszar wymagający konserwacji.
- Możliwość ponownego użycia: definicję obiektu można używać wiele razy w wielu częściach systemu lub potencjalnie w innych systemach. Ponowne wykorzystywanie kodu pozwala oszczędzić czas i pieniądze — zmniejsza ilość kodu do napisania i przyspiesza osiągnięcie celu.
Modelowanie systemu w programowaniu obiektowym
Oprogramowanie tworzy się często z potrzeby przyspieszenia działania, zwiększenia wydajności i ograniczenia występowania błędów w określonym procesie. W niektórych przypadkach ludzie po prostu nie mają szans w konkurencji z oprogramowaniem, gdy chodzi o szybkość procesu. Korzystanie z programowania obiektowego polega nie tylko na modelowaniu, ale też na pisaniu kodu w celu wdrożenia logiki opracowanego modelu. Modelowanie polega na uczeniu się identyfikowania aktorów, potrzebnych danych i typu interakcji. Do utworzenia modelu systemu wystarczy zapoznanie się z jego opisem.
Analiza przypadku — system do zarządzania fakturami
Przyjrzyjmy się przepływowi ręcznego, z jakim zmaga się wiele firm, a mianowicie z zarządzaniem fakturami. Wiele firm otrzymuje faktury, które muszą być terminowo regulowane. Opóźnione płatności oznaczają kary za opóźnienie, czyli niepotrzebne koszty. Jednak aby można było opłacić fakturę, należy ją przetworzyć. Często faktura przechodzi przez ręce kilku osób, zanim zostanie ostatecznie zarejestrowana w odpowiednim miejscu i opłacona.
Proces zwykle rozpoczyna się od początkowej fazy sortowania, w której faktura jest wysyłana do odpowiedniego działu. Następnie sprawdzana jest jej poprawność, po czym fakturę zatwierdza osoba z odpowiednim poziomem uprawnień. Na koniec faktura zostaje opłacona. W przypadku małej firmy wszystkie te czynności może wykonywać właściciel. W dużych firmach zaangażowanych będzie wiele osób i procesów, co sprawia, że zarządzanie fakturami staje się złożonym zadaniem.
Co ten opis ma wspólnego z programowaniem obiektowym? Jeśli wcześniejszy przepływ pracy — który jest często przepływem ręcznym — i przekształcił go w napisane oprogramowanie, pierwszą rzeczą, którą należy wykonać, jest próba modelowania systemu. W kontekście zarządzania fakturami, czytając opis domeny problemu, zaczynamy dostrzegać aktorów (obiekty), zachowania i dane.
Gdy zaczniesz dostrzegać w opisanej domenie fazy, dane wejściowe, przetwarzanie i dane wyjściowe, możesz uzupełnić informacje na przykład w formie takiej tabeli:
| Faza | Co |
|---|---|
| Dane wejściowe | Faktura |
| Trwa przetwarzanie | Sortowanie, zatwierdzenie, odrzucenie |
| Wyjście | Płatność |
W powyższej tabeli opisano, co działo się w każdej fazie. Udało Ci się znaleźć dane, rzeczy, które zdarzają się do danych podczas przetwarzania, oraz ostateczny wynik, czyli płatność. Na tym etapie można rozwiązać problem przepływu pracy w systemie zarządzania fakturami przy użyciu dowolnie wybranego podejścia. Jak zastosować tutaj programowanie obiektowe?
Znajdowanie obiektów, danych i zachowań
Aby znaleźć poszczególne artefakty w systemie, można zadać następujące pytania:
- Kto z kim wchodzi w interakcje?
- Kto co robi i z kim?
Rozważając te pytania, możesz określić instrukcje. Wyróżnimy poszczególne artefakty w tych instrukcjach, aby było jasne, które części są ważne dla systemu.
Usługa poczty dostarcza fakturę do systemu.
Faktura jest sortowana na podstawie kodu referencyjnego lub ręcznie przez osobę sortującą, aby mogła trafić do właściwego działu.
Faktura jest zatwierdzana lub odrzucana przez osoby zatwierdzające na podstawie czynników, takich jak (na przykład) poprawność i rozmiar kwoty.
Faktura zostaje opłacona przez osobę obsługującą płatności przy użyciu zawartych na niej danych do płatności.
Teraz możesz wyodrębnić z tych instrukcji obiekty, dane i zachowania, które uporządkujesz w tabeli w następujący sposób:
| Faza | Aktor | Zachowanie | Data |
|---|---|---|---|
| Dane wejściowe | Operator poczty | Dostarcza | Faktura |
| Dane wejściowe | System | Odbiera | Faktura |
| Trwa przetwarzanie | Osoba sortująca lub system | Sortuje lub kieruje | Faktury (kody referencyjne) |
| Trwa przetwarzanie | Osoba zatwierdzająca | Zatwierdza lub odrzuca | Faktury (kwoty) |
| Wyjście | Osoba obsługująca płatności | Opłaca | Faktury (dane do płatności) |
W pierwszym opisie systemu do zarządzania fakturami wiele się zmieniło. Znaleziono aktorów (obiekty). Określono istotne dane i pogrupowano je wraz ze znalezionymi obiektami. Rozpoznano także zachowania, dzięki czemu lepiej wiadomo, którzy aktorzy (które obiekty) wchodzą ze sobą w interakcje. W efekcie możesz określić dokładnie kto wykonuje jakie zachowania względem kogo. Mamy już za sobą wstępną analizę — to świetny początek. Pozostaje jednak pytanie, jak przekształcić tę analizę w kod? Nad odpowiedzią na to pytanie będziemy pracować właśnie w tym module.
Uwaga
Rzeczywisty system do zarządzania fakturami będzie prawdopodobnie znacznie bardziej złożony i może korzystać ze znacznie większej ilości danych i zależności logicznych. Zdolność do modelowania systemu w ten sposób oznacza, że podchodzisz do problemu w sposób ustrukturyzowany.