Moda na krytykowanie OOP-u

2011-03-19 20:47

Nauczyłem się już lubić fakt, że w przypadku informatyki powiedzenie o “ciekawych czasach” jest truizmem, bo ciekawie jest po prostu zawsze – głównie ze względu na tempo zmian w wielu dziedzinach. Nawet w tych, wydawałoby się, zastygłych na lata. Niecałe trzy lata temu zżymałem się na przykład na zbytnią ufność w doskonałość obiektowych metod programowania. Dzisiaj zaś przychodzi mi robić coś zdecydowanie przeciwnego.
Programowanie obiektowe jest obecnie sztandarowym kozłem ofiarnym i chłopcem do bicia, otrzymującym ciosy z wielu stron. Już nie tylko programiści gier twierdzą, że nie mogą sobie na nie pozwolić ze względu na wydajność i zamiast niego forsują Data Oriented Design. Pokazywałem niedawno, że sprzeczność między tymi dwoma podejściami jest raczej pozorna niż rzeczywista. Teraz natknąłem się na interesującą opinię, która podważa sens OOP-u jako metodologii, wychodząc z nieco innego punktu widzenia niż wydajność dla celów grafiki real-time:

Object-oriented programming (…) is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. [pogrubienie moje]

Anty-modularne i anty-współbieżne? Oczywiście; da się napisać kod obiektowy, który te dwa warunki będzie spełniał doskonale. Ale to nie oznacza, że każdy kod obiektowy je spełnia, a to właśnie jest implikowane powyżej. Nie da się tego określić inaczej niż jako stereotyp – i to w modelowej wersji, czyli negatywnego uogólnienia z pojedynczych przypadków.

Jako antidotum na te rzekome bolączki OOP-u często wymieniane jest programowanie funkcyjne. Nie ujmując mu niczego ze swojej elegancji, nie mogę jednak nie zauważyć, że zamiata ono wiele problemów pod dywan. Określanie wykonania programu jako serii transformacji danych nie rozwiązuje jednak problemu: gdzie i jak te dane mają być zapisywane i chronione przed równoczesnym dostępem z wielu ścieżek wykonania. Sytuacje, w których programowanie funkcyjne lub quasi-funkcyjne sprawdza się dobrze to takie, gdzie problemy te dały się w miarę łatwo rozwiązać. Tak jest chociażby w przypadku vertex i pixel shaderów, gdzie podział danych wejściowych i wyjściowych na rozłączne bloki jest wręcz naturalny. Fakt ten nie jest jednak zasługą programowania funkcyjnego, tylko natury zagadnienia – w tym przypadku renderowania grafiki opartej na wielokątach.

I właśnie o tym powinniśmy pamiętać, gdy wyzłośliwiamy się nie tylko na OOP, ale dowolny inny paradygmat programowania. Otóż porzucenie go nie sprawi od razu, że magicznie zaczniemy pisać kod doskonale modularny. A już nie pewno nie spowoduje, że niezwykle trudne zagadnienia współbieżności staną się nagle banalnie proste. To niestety tak nie działa.
Nie znaczy to oczywiście, że nie powinniśmy poszukiwać nowych, lepszych metodologii do konkretnych zastosowań. Dlatego przecież wiele języków (np. C++, C#, Python) ewoluuje w kierunku wieloparadygmatowości, aby możliwe było dobranie właściwych narzędzi dla danej sytuacji. Nie wydaje mi się jednak, aby uleganie trendy nurtom krytykowania jakichkolwiek rozwiązań poprzez odwoływanie się do stereotypów i nieuzasadnionych wyobrażeń o nich było w tym procesie specjalnie produktywne. Zdaję sobie jednak sprawę, że “funkcje wirtualne to zuo!” brzmi lepiej niż “wywoływanie funkcji wirtualnych skutkuje narzutem wydajnościowym związanym z dodatkowym adresowaniem pamięci (które nie jest cache-friendly) i może powodować niepożądane skutki uboczne, jeśli ich wersje w klasach pochodnych nie są thread-safe“. Mam jednak nadzieję, iż nikt nie ma wątpliwości, które z tych dwóch stwierdzeń jest bardziej racjonalne.

Podziękowania dla Rega za podesłanie linków, które zainspirowały mnie do podjęcia tego tematu.



7 comments for post “Moda na krytykowanie OOP-u”.
  1. vashpan:
    March 20th, 2011 o 9:58

    Hmm, true ;)

  2. MSM:
    March 20th, 2011 o 17:15

    Ktoś kto to napisał zdecydowanie przesadził… Owszem – programowanie funkcyjne jest 100% thread-safe. Z prostego powodu – nie występują w nim efekty uboczne. Dlaczego nie występują? Bo w językach czysto funkcyjnych nie ma instrukcji przypisania (wartość zmiennej nie może się zmienić w czasie). O ile jest to bardzo przyjemne podczas pisania, po jakimś czasie opanowanie tych wszystkich funkcji jest coraz trudniejsze. Polacam również wyobrażenie sobie jakiegoś naprawdę dużego projektu napisanego czysto funkcyjnie (jedyny przykład sporego projektu z GUI wykonanego w Haskellu jaki znam to Leksah – IDE do… Haskella.)

    Dalej – nie zgodzę się z tym że programowaie funkcyjne w jakiś lepszy sposób rozwiązuje modularność. Ja bym się nawet zastanawiał nad twierdzeniem przeciwnym. Chętnie usłyszałbym od autora argumenty potwierdzające jego tezę (poważnie, może po prostu o czymś nie wiem…)

    No i obiekty są zdecydowanie prostsze do wyobrażenia sobie niż funkcje…

  3. Piotr:
    March 20th, 2011 o 20:02

    Hmmm autor chyba nie wiele wie o “realiach” OOP
    Polecam wyszukac w sieci wywiadu z ‘autorem’ C++ – bo chyba go nie czytal – po jego lekturze – zdziwi sie bardzo :))

  4. Kos:
    March 20th, 2011 o 22:51

    Xion, błagam- funkcyjne, nie funkcjonalne… Mamy w języku polskim dwa różne tłumaczenia dla różnych znaczeń ‘functional’ i to nie są synonimy, będę się przy tym upierał aż osiwieję. :)

  5. Xion:
    March 21st, 2011 o 0:47

    D’oh, masz rację. Wpadka :) Już poprawiam.

  6. shoter:
    March 21st, 2011 o 18:59

    “każdy kod obiektowy jest spełnia”
    jest zmień na ‘je’

Comments are disabled.
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.