Web Design Blog / Programowanie:

Zalety i wady programowania obiektowego

Data publikacji: 5 maja 2018

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) procesor ma gdzieś, czy kod jest czytelny czy nie oraz to 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. Oczywiście, to odbija się także na doświadczeniach użytkownika. 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.

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.

nieodpowiedni do małych projektów – małe projekty nie są w stanie wykorzystać w pełni zalet płynących z programowania OOP. Kod będzie mniej elastyczny, pisania też będzie więcej i koszt też będzie większy.

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 co z tego jeżeli klient ani użytkownicy tego kodu nigdy nie zobaczą na oczy? 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




Zalety i wady programowania obiektowego
4.5 (90.91%) głosów: 11


Komentarze

Brak komentarzy.

Dodaj swój komentarz