Obiektowy szowinizm

Od jakiegoś czasu najpopularniejszymi językami programowania są albo te stricte obiektowe, albo chociaż oferujące przynajmniej najważniejsze cechy tego modelu programowania (czyli dziedziczenie, polimorfizm i metody wirtualne). Prawdopodobnie większość powstającego kodu realizuje więc założenia OOP-u co najmniej w takim stopniu, że można go uznać za spełniający paradygmat obiektowy – albo chociaż podpadający pod obiektowość bardziej niż pod cokolwiek innego.
Ano właśnie: warto od czasu do czasu zauważyć, że oprócz OOP-u istnieje też “coś innego”, i że obiektowy model programowania wcale nie jest jedynym. Nie musi być on też ani ostatecznym, ani najbardziej uniwersalnym. A już tym bardziej nie jest on jedynie słusznym.

Jako koderzy podążający za wytycznymi programowania obiektowego często jednak tak uważamy – mniej lub bardziej świadomie. Zwłaszcza, że obecnie można zajmować się programowaniem całkiem długo i nawet nie słyszeć o innych paradygmatach niż obiektowy. A jeśli nawet ktoś na podobne “ciekawostki” lub na “dziwaków” opowiadających się na innym podejściem do kodowania, to najpewniej nie będzie to miało żadnego wpływu na jego dobre samopoczucie i przekonanie o wyższości OOP-u nad czymkolwiek innym.
Bo przecież łatwo znaleźć programistów myślących bardzo podobnie i bez wysiłku wyciągnąć całe mnóstwo silnych argumentów na poparcie swoich racji. Bodaj najczęściej wykorzystywanym jest ten mówiący o odpowiednim poziomie abstrakcji, który jest jakoby immanentną cechą programowania obiektowego. Z jednej strony jest on bowiem wyższy od brzydkiego programowania strukturalnego, dzięki czemu kod obiektowy łatwiej jest napisać i zrozumieć. Jednocześnie nie jest to też poziom zbyt wysoki, przez co nadal wiadomo, jak nasz program działa i jak z grubsza sprawuje się pod względem wydajnościowym. Tego samego nie można rzecz jasna powiedzieć wtedy, gdy kodujemy funkcyjnie czy deklaratywnie.

Wszystko to brzmi rozsądnie i wydaje się słuszne. W rzeczywistości jednak posługiwanie się takimi kryteriami jest zwykłym nadużyciem. Na takiej zasadzie można by narzekać na to, że nie da się przygotować omletu przy pomocy samego widelca (że pozwolę sobie posłużyć się analogią kulinarną ;]). Należy bowiem zawsze mieć na uwadze to, o jakim zastosowaniu mówimy. Programowanie nie jest przecież dziedziną abstrakcyjną, ale jak najbardziej praktyczną, niezależnie od tego, jak bardzo usiłowalibyśmy ją steoretyzować.
Dlatego też absurdem jest twierdzenie o wyższości programowania obiektowego nad innymi paradygmatami. Bo czy bawilibyśmy się w tworzenie klas w przypadku takiego oprogramowania jak firmware procesora czy karty graficznej, działającego w ścisłym powiązaniu ze sprzętem? I czy odpowiadałoby nam, gdyby zamiast określania za pomocą znaczników wyglądu fragmentów strony WWW bylibyśmy zmuszeni tworzyć dla każdego z nich osobny obiekt i ustawiać jego właściwości?…

Nie zamykajmy się więc w swoim obiektowym światku, nawet jeśli czujemy się w nim nadzwyczaj dobrze. Znajomość innych sposobów kodowania może nam bowiem tylko pomóc.

Be Sociable, Share!

• 
• 

Be Sociable, Share!

• 
• 

• Tweet
•