Programowanie obiektowe

Witam Was czytelnicy, chciałbym Wam wytłumaczyć lub przypomnieć co oznacza programowanie zorientowane obiektowo. Problem polega na tym, że każdy programista ponoć wie co to znaczy. A zwłaszcza Ci po studiach. Tylko, że z czasem pisząc w różnych projektach okazuje się, że pomimo używania języka obiektowego, nasz kod jest daleki od założeń paradygmatu programowania, który chcemy stosować.

Programowanie obiektowe

Jest to paradygmat programowa w którym problemy przedstawiamy jako zbiór obiektów komunikujących się ze sobą oraz posiadających jakiś stan. Zbliżony on jest do codziennego myślenia człowieka.

Chętnie podam przykład dla wyjaśnienia.

Pomyślmy o człowieku jako problemie, który chcemy zaimplementować. Dajmy mu możliwość odkręcania śrubek. Oczywiście człowiek człowiekowi nie równy i każdy ma swoją technikę, doświadczenie, siłę, zręczność i cokolwiek innego co jest potrzebne do tej czynności. I tutaj właśnie użyliśmy myślenia obiektowego dla obiektu człowiek. Ma on swoje atrybuty wpływające na czynność którą wykonuje (stan) oraz właśnie tą czynność. Pomimo, że każdemu takiemu obiektowi, drugi obiekt np. "kierownik człowieka", może rozkazać wykonanie odkręcenia śrubki w zależności od stanu obiektu, będzie to wykonane zupełnie inaczej. A kierownik nie ma nawet na to wpływu, a wręcz nie powinien wiedzieć od czego to zależy oraz jak to jest wykonywane. Dla niego liczy się tylko efekt, czyli odkręcona śrubka.

Zalety takiego rozwiązania:

  • myślenie o problemach zbliżone do codziennego,
  • automatyczne grupowanie obiektów, czynności oraz danych,
  • łatwiejsze czytanie oraz implementacja kodu,
  • raz zaimplementowane obiekty, można zastosować w różnych projektach

Pomimo, tych zalet nie zawsze łatwe jest zaimplementowanie czegoś w ten sposób. I nie jest to zawsze najlepsze rozwiązanie. Pamiętać trzeba, aby nie programować tym sposobem na siłę.

Mechanizmy oraz pojęcia, które zostały zastosowane w ramach programowania obiektowego (czasami interpretowane jako cechy programu obiektowego)

  • Dziedziczenie
  • Jest to sposób rozszerzenia obiektów o kolejne możliwości (a raczej tak powinno to wyglądać). Polega to na tym, że obiekt podrzędny posiada cechy, atrybuty oraz funkcje obiektu nadrzędnego (oczywiście jeżeli ich nie zmieni).

  • Polimorfizm
  • Jest to wyodrębnienie wspólnych czynności obiektów do jakiejś abstrakcji oraz wykorzystywanie tej czynności w jednolity sposób pomimo różnorodności ich wykonania. Np. każde zwierzę je i pije, ale w zależności jaki on jest robi to na różne sposoby. Jakbyśmy chcieli powiedzieć wszystkich zwierzętom, aby się napili i zjedli to tutaj pomaga nam właśnie polimorfizm. Pozwala użyć naszej abstrakcji zwierzęcia do zlecenia wykonania tej czynności. Nie zastanawiamy się w jaki sposób oraz nawet jakiemu zwierzęciu każemy jeść. On ma po prostu to wykonać.

  • Hermetyzacja
  • Jest to ukrycie implementacji obiektu. Użytkownik obiektu, nie powinien mieć możliwości zmiany jego stanu. A nawet mieć możliwości podejrzenia jego (jeżeli on tego nie chce). Zadeklarowane są jawne funkcjonalności, które umożliwiają dokonanie jakiejś zmiany. Zasadę można wytłumaczyć na przykładzie zwierzęcia. Dopóki zwierzę czegoś nie zje nie będzie najedzony, nie zwiększy się jego masa, ani inne rzeczy na które wpływa jedzenie. Nie da się jemu powiedzieć rośnij i będzie rosnąc. Analogicznie także nic nie da powiedzenie "bądź najedzony".

Podsumowując

Mam nadzieję, że przybliżyłem czym jest programowanie zorientowane obiektowo. Być może kogoś przekonałem do zastanowienia się czy na pewno tak programuje. Wpis powstał w trakcie moich przemyśleń o programowaniu obiektowym w moich projektach. Pomimo, że wiedziałem czym to jest i jak to się robi, pod osłoną codziennej pracy nie zorientowałem się, że nie zawsze to stosuje. Czekam na Wasze komentarze oraz pytania.

Comments

Popular posts from this blog

Why TDD is bad practice?

How correctly imitate dependencies?

Software development using Angular 5 with Spring Boot