Programowanie orientowane obiektowo (object oriented programming) (bo właśnie tak powinna brzmieć prawidłowa nazwa) to paradygmat programowania, czyli taki zbiór teorii, zasad według których powinno się programować. Śmiało można powiedzieć, że programowanie orientowane obiektowo to jak na razie najpopularniejsza i najczęściej używana technika produkcji oprogramowania, gdzie w projekty zaangażowanych jest wiele osób.
O co w tym wszystkim chodzi?
Pisząc program w sposób zgodny z OOP, definiujemy abstrakcyjne obiekty, które posiadają pola (czyli dane) i metody (czyli funkcje/procedury). Obiektowy program to taki, który polega na stworzeniu takich obiektów a potem mechanizmów umożliwiających komunikację pomiędzy tymi obiektami. W dużym uogólnieniu programowanie takie ma naśladować działanie świata naturalnego.
W programowaniu obiektowym nie chodzi o to by za pomocą klas i obiektów zorganizować kod. Używanie klas i obiektów do powiązania ze sobą niezwiązanych pól i metod nie jest podejściem obiektowym.
Podejście obiektowe ma w założeniu spełnić nadrzędny cel – stworzenie wyższej abstrakcji, którą będzie można praktycznie wykorzystać.
Podstawowe założenia OOP
Abstrakcja – obiekty to abstrakcyjne byty, które mają swój stan i własne metody. Może to być obiekt klasy „Użytkownik”, który ma pola „imię”, „data urodzenia” i ma metody typu dodajDoZnajomych(); To założenie powoduje, że kod jest naturalnie zrozumiały i tworzy analogię programu do świata rzeczywistego.
Hermetyzacja (lub Enkapsulacja) – to ukrywanie implementacji polegające na tym, że nie można bezpośrednio przypisywać wartości do pól innych obiektów w nieoczekiwany sposób. Każdy obiekt udostępnia interfejs, który określa jak można te dane zmienić. To założenie wprowadza porządek i bezpieczeństwo w kodzie.
Polimorfizm – metody klas mogą być wykorzystywane na wiele sposobów w zależności od sytuacji. To założenie powoduje, że nie powtarzamy kodu.
Dziedziczenie – umożliwia definiować specjalizowane obiekty na podstawie bardziej ogólnych. Dzięki temu mechanizmowi też nie powtarzamy kodu.
Zalety programowania obiektowego
czytelny kod – poprawne użycie mechanizmu polimorfizmu i dziedziczenia powoduje, że nie robimy kopiuj-wklej w kodzie. Raz napisany kod jest używany wiele razy nawet wtedy kiedy jest wykorzystywany dla różnych danych i w różnych sytuacjach.
modularna budowa – partie kodu można łatwiej przenieść do innego programu. Można podzielić program na kawałki a to ma same zalety.
spójna ideologia zarządzania kodem – jest to obecnie praktycznie jedyny paradygmat, którego opanowanie umożliwi efektywną pracę w zespołach.
możliwość kontrolowania dużego projektu – podobnie jak wyżej. Im większy projekt tym zalety OOP przeważają nad jego wadami. Dzięki uniwersalnym zasadom OOP programistom, którzy wchodzą do projektu łatwiej jest się wdrożyć i szybciej rozpocząć użyteczną dla tego projektu pracę.
stabilność i możliwość rozwoju – dzięki mechanizmom OOP można rozbudowywać i rozszerzać oprogramowanie
Wady OOP
mniejsza wydajność – (szczególnie w kodzie interpretowanym) procesora nie interesuje estetyka kodu lub to czy jest czytelny dla człowieka i czy nowym programistom łatwo jest się do niego wdrażać. Tam gdzie OOP służy programistom i zarządzaniu projektem staje się problemem dla procesora, ogólnej wydajności i prędkości wykonywania. Tam gdzie wydajność to priorytet nadal korzysta się z programowania funkcyjnego i proceduralnego. Sprawdź jak jest pisany i optymalizowany kod odpowiedzialny za animacje czy zaawansowane renderowanie grafiki.
Dowiedz się więcej z artykułu na temat Data-Oriented Design z Wikipedii: https://en.wikipedia.org/wiki/Data-oriented_design
większy koszt utrzymania aplikacji – skoro mniejsza wydajność aplikacji to jej utrzymanie aplikacji np. webowej będzie droższe, ponieważ będzie wymagała szybkiego procesora i pamięci RAM. Wszelkie prace są trudniejsze do wykonania i wiążą się z pisaniem większej ilości linijek kodu, są przez to gorzej skalowalne we wczesnych etapach ewolucji i warunkach start-upowych.
utrudnione testowanie i debugowanie – śledząc działanie kodu proceduralnego możemy łatwo analizować krok po kroku rezultaty poszczególnych instrukcji. W kodzie który obiekty „coś robią” z danymi tego typu podejście jest utrudnione. Programista musi sam dbać za pomocą wyjątków aby złożony kod był możliwy do debugowania.
mniejsza elastyczność – hermetyzacja i dziedziczenie powoduje, że kod w różnych miejscach jest powiązany ze sobą skomplikowanymi zależnościami i pewnego rodzaju hierarchią. Wtedy trudno zmienić rdzenne funkcje programu a każda taka zmiana może się wiązać z koniecznością przebudowy kodu w wielu miejscach lub będzie zwyczajnie niemożliwa. Pozornie błahe zmiany mogą wymagać sporych zmian w kodzie.
nie rozwiązuje wszystkich problemów programowania – są pewne klasy problemów, których nie można przepisać na szkielet zasad OOP i potrzeba proceduralnego podejścia. Wiele modnych ostatnio zagadnień związanych ze sztuczną inteligencją i uczniem maszynowym dużo łatwiej pisać w stylu który odchodzi od klasycznego OOP.
nieodpowiedni do małych projektów – małe projekty nie są w stanie wykorzystać w pełni zalet płynących z programowania OOP. Jeżeli w kodzie używamy kilku funkcji na krzyż dodanie słowa kluczowego class i użycie operatorów obiektowych ani nie zrobi nas lepszych programistów anie nie zwiększa czytelności kodu.
Problem z językami zorientowanymi obiektowo polega na tym, że mają całe to ukryte środowisko, które „noszą” ze sobą. Chciałeś banana, ale masz goryla trzymającego banana i całą dżunglę.
– Joe Armstrong „Coders at work – Reflections on the Craft of Programming”
Jak nauczyć się dobrego OOP?
Praktycznie nie jest możliwe samodzielne wytworzenie oprogramowania bazującego na kodzie OOP po jakimś kursie czy paru latach praktyki w taki sposób aby faktyczne korzyści jakie ma przynosić OOP były możliwe do zauważenia.
Siedzenie przy książkach lub studiowanie cudzego kodu uważam za bardzo nienaturalny tok nauki programowania. Co innego, kiedy pracujemy z bardziej doświadczonymi programistami nad projektem, który stworzyli jeszcze bardziej doświadczeni programiści. Wtedy inwestycja w naukę OOP jest bardzo opłacalna.
O co chodzi z tą wydajnością?
Programy napisane obiektowo mają jakby kolejną warstwę abstrakcji. To powoduje że – OK kod wygląda ładnie i w programie zaszyte są eleganckie mechanizmy typu MVC ale taki kod zazwyczaj wymaga większych zasobów procesora. To prawda, ludzki mózg pracuje na obiektach… ale nie procesor.
W retoryce broniącej zasadności stosowania OOP podnosi się korzyść z operowania na obiektach tak jak w świecie naturalnym. To fajnie wygląda i kod wygląda cool…
A tak na poważnie…
Czy obiekty w świecie rzeczywistym faktycznie udostępniają interfejs do zmiany własnych stanów? Czy pozycja na fakturze jest zwykłą tablicą danych, wartości których mogą być wyliczane za pomocą funkcji czy instancją klasy, która komunikuje się za pomocą interfejsów z innymi obiektami?
Warto mieć na uwadze, że można napisać zły kod, w każdym stylu programowania. OOP nie powoduje że zły kod staje się dobry tak samo podejście proceduralne czy funkcyjne nie jest w żaden sposób lepsze czy gorsze. Czy przy pisaniu kodu naprawdę musimy zahaczać o filozofię bytów i platoniczny esencjalizm? Czy po prostu programujemy maszynę aby zrobiła to co chcemy?
Podsumowanie
Niezależnie jaki projekt piszemy i jakiego używamy języka, programowanie od lat pięćdziesiątych sprowadza się do trzech zasadniczych działań:
- przypisania
- instrukcji if
- pętli while
Używajmy podejścia OOP tam, gdzie jest to konieczne lub uzasadnione a korzyści przewyższają wady takiego rozwiązania.
Źródła
https://www.researchgate.net/publication/2419984_Performance_Impact_of_Object_Oriented_Programming
Odpowiedz lub skomentuj