Często słyszy się, że programowanie obiektowe jest standardem w IT. W rzeczywistości OOP (Object Oriented Programming) jest tylko jedną z wielu technik, w dodatku nie dominującą i powszechnie odradzaną. Popularność w niektórych kręgach zawdzięcza zamknięciu w bańce informacyjnej, gdzie przekaz „dobry kod to kod obiektowy” podawany był tak często, że dla wielu stał się oczywistością. Tymczasem większość profesjonalnego oprogramowania powstaje bez użycia OOP, a w dużych firmach jak Google, Apple czy Cloudflare OOP jest czymś, czego świadomie się unika.

Chciałeś banana, ale dostałeś goryla trzymającego banana

Krytyka programowania obiektowego płynie wprost od samych twórców idei. Amerykański naukowiec Alan Kay, współtwórca OOP, wielokrotnie podkreślał, że współczesna hierarchia klas, dziedziczenie i wzorce to wypaczenie pierwotnych założeń obiektowości.

W podobny sposób podsumował to Joe Armstrong, twórca Erlanga: „Problemem języków obiektowych jest cały ten ukryty stan, który ze sobą niosą. Chciałeś banana, a dostałeś goryla trzymającego banana i całą dżunglę w pakiecie”.

Armstrong zaprojektował Erlanga jako język nieobiektowy, by rozwiązać problemy, z którymi OOP sobie nie poradziło: masową współbieżność i odporność na błędy. W Erlangu napisano komunikator społecznościowy WhatsApp, języka używa także Facebook, Samsung, T-Mobile, MasterCard, Ericsson i Nintendo.

Linus Torvalds, twórca Linuxa i Gita, jest znany z krytyki OOP. Według niego OOP prowadzi do nieefektywnych sposobów programowania oraz przyciąga programistów, którzy skupiają się na budowaniu skomplikowanych rozwiązań zamiast na tym, co program faktycznie ma robić.

John Carmack, legendarny twórca gier Doom i Quake, przez lata odchodził od programowania obiektowego, ewoluując w stronę programowania funkcyjnego. Carmack zwraca uwagę, że największym problemem, jaki rozwiązuje IT, jest stan (state). OOP zachęca do rozproszenia stanu w tysiącach obiektów, klas i wzorców, co staje się koszmarem pod kątem wydajności, debugowania i rosnącej logiki. Carmack mówi: „Czasem eleganckim rozwiązaniem jest po prostu funkcja. Nie metoda, nie klasa, nie framework. Po prostu funkcja”.

Casey Muratori, ekspert programowania niskopoziomowego, udowodnił na liczbach, że towarzyszące OOP paradygmaty jak polimorfizm czy hermetyzacja drastycznie obniżają wydajność. Według niego „clean code” oparty na OOP to przepis na powolne oprogramowanie. Muratori mówi: „Obiektowy sposób myślenia o rzeczach jest niemal diametralnie sprzeczny z tym, jak faktycznie działa komputer. To błąd trwający 35 lat”.

Rich Hickey, twórca języka Clojure (następca Javy), krytykuje OOP za mieszanie danych z logiką, co prowadzi do błędów, których nie da się uniknąć w średnich i dużych systemach. Hickey mówi: „Uważam, że duże obiekty to grafy, a grafy to słaby sposób na reprezentowanie informacji. Obiekty są jak marionetki: pociągasz za sznurek tutaj, a noga rusza się tam i nie wiesz dlaczego”.

Paul Graham, twórca Lisp, zauważył, że OOP jest często wymuszane przez korporacje, bo ułatwia zarządzanie przeciętnymi programistami, a nie dlatego, że tworzy lepszy kod. Graham mówi: „Programowanie obiektowe oferuje zrównoważony sposób pisania kodu dla ludzi, którzy nie muszą rozumieć tego, co robią”. Dodaje również, że „niebezpieczne jest tworzenie oprogramowania w oparciu o dodawanie rzeczy, których nigdy się nie potrzebowało [OOP], tylko dlatego, że uważa się to za dobry pomysł”.

Z kolei Ted Neward już w 2004 roku nazwał mapowanie obiektowo-relacyjne (ORM) „Wietnamem informatyki”. Praktyka pokazała, że traktowanie rekordów bazy jako obiektów tworzy wąskie gardła. Badania towarzyszące temu zjawisku wykazały, że niemal 80% projektów korzystających z ORM jest zmuszone dorabiać z boku zwykłe zapytania do bazy, aby ominąć ograniczenia ORM i zwiększyć wydajność. Dziś ORM jest podejściem typu legacy, ale branża wciąż powiela błędy przeszłości, przesiadając się bezrefleksyjnie na GraphQL.

Duże firmy nie korzystają z obiektowości lub od niej odchodzą

Gdy w grę wchodzą prawdziwe pieniądze, bezpieczeństwo lub skala, entuzjazm wobec OOP znika. Systemy operacyjne, przeglądarki, serwery proxy, narzędzia sieciowe czy infrastruktura chmurowa są dziś pisane w językach, które świadomie odrzucają klasyczne obiekty. Rust, Go czy C wygrywają tam, gdzie liczy się kontrola nad pamięcią i wydajność, na którą w obiektowej dżungli po prostu nie ma miejsca.

Na początek kilka faktów dla fanów OOP, którzy nie wyszli jeszcze ze swojej bańki informacyjnej. Spójrzmy, co od 15 lat dzieje się w IT.

W 2010 roku Apple ogłosiło, że porzuca język Objective-C na rzecz zaprojektowanego przez siebie hybrydowego Swifta. Od tego momentu miliony aplikacji na iPhony i iPady powstają głównie jako kod funkcyjny. Język Swift ma wbudowaną obiektowość, ale pozostawiono ją dla kompatybilności ze starym kodem. Język mocno wspiera programowanie strukturalne, gdzie funkcje są tzw. „obywatelami pierwszej klasy”, z głównym naciskiem na struktury (value types) i programowanie zorientowane na protokoły.

Ten sam ruch zrobiło Google, migrując z obiektowej Javy do hybrydowego Kotlina. W 2019 roku firma ogłosiła, że stawiający na funkcje Kotlin staje się głównym i preferowanym językiem do tworzenia aplikacji na Androida. Od tego momentu większość aplikacji na system mobilny Google tworzona jest w tym języku. Kotlin, podobnie jak Swift, nie jest nieobiektowy, ale świadomie łamie dogmaty klasycznego OOP. Zaprojektowano go pod silne podejście funkcyjne i kompozycję, co jest zaprzeczeniem programowania obiektowego.

W 2007 roku Google zaprezentowało nieobiektowy język Go (zwany Golang). Z roku na rok kolejne usługi firmy były przepisywane z obiektowej Javy do Go, a nowe projekty od pierwszej linii kodu były pisane w tym języku. Twórcy Go świadomie odrzucili klasyczne OOP, krytykując je za złożoną hierarchię klas, nadużywanie dziedziczenia oraz wzorce projektowe nazywane antywzorcami. Dzięki podejściu funkcyjnemu zapewniono większą prędkość działania, niższą awaryjność, lepszą czytelność i łatwiejszą refaktoryzację.

Język przyjął się szeroko na rynku. W nieobiektowym Go został stworzony Docker, Kubernetes, Prometheus, Grafana i Terraform. Go jest głównym językiem używanym przez Ubera. W 2013 roku na Go przeszedł komunikator Twitch. W tym samym roku popularna chmura Dropbox przeszła z Pythona na Go. Z języka Go korzysta m.in. największe repozytorium muzyki SoundCloud, a także Netflix, Disney, Facebook, BBC czy amerykańskie banki. Również Microsoft korzysta z Go w swojej chmurze Azure.

Cloudflare: od obiektowego C++ i PHP do nieobiektowego Go, następnie do nieobiektowego Rusta

Ciekawym przypadkiem jest Cloudflare. Usługa do 2012 roku była tworzona ze wsparciem obiektowych języków C++ i PHP. W 2013 w celu zwiększenia wydajności usługę przepisano z użyciem nieobiektowego Go. Język ten zasilał usługę przez ponad dekadę. Aż do 2025 roku, gdy kod przepisano do nieobiektowego Rusta.

Przykład Cloudflare pokazuje, że migracja z OOP do programowania funkcyjnego nie jest przypadkiem. Firma nie przepisała swojego kodu na Rusta dlatego, że „Rust jest modny”. Wybrano kolejny raz język funkcyjny z powodu rosnących wymagań wydajności i bezpieczeństwa. Alternatywne modele obiektowe były zbyt ciężkie, ryzykowne i kosztowne w utrzymaniu.

Z nieobiektowego Rusta korzysta również Amazon Web Services (AWS), Meta (Facebook) czy komunikator Discord. W 2025 roku Microsoft ogłosił, że migruje z C++ do Rusta przy rozwoju Windowsa i innych projektów.

Studium przypadku: jak OOP paraliżuje projekt

Ten konkretny przypadek jest często przytaczany na konferencjach IT.

W pewnej zachodniej firmie zespół programistów stanął w obliczu problemu, który większość adeptów programowania obiektowego uznałaby za absurdalny: nie mogli ogarnąć własnego projektu. Kod był „poprawny” - audyty dwóch pierwszych firm wykazały, że wszystko zostało napisane obiektowo, zgodnie ze wzorcami i zasadami SOLID, do tego pełne testy jednostkowe i dokumentacja.

Dopiero trzecia firma audytorska odkryła problem. Okazało się, że projekt był naprawdę skrajnym przykładem „czystego OOP”. Tysiące klas i metod, często użytych tylko raz lub tworzonych na zapas. Ogromna liczba abstrakcji, fabryk i interfejsów. Setki warstw dziedziczenia i nadmiarowych wzorców. Szybko policzono, że ponad 90% kodu było zupełnie niepotrzebne.

Rozwiązanie było zaskakująco proste. Zespół natychmiast rozwiązano, a do projektu oddelegowano dwóch programistów z innego zespołu, którzy - stosując podejście funkcyjne - w ciągu jednego miesiąca stworzyli działające MVP. Wystarczyło kilkanaście dobrze napisanych funkcji, które wykonywały dokładnie to samo, co tysiące klas i metod OOP tworzonych przez kilka lat.

Historia ta jest przestrogą dla fanów OOP: nadmiar obiektowości może paraliżować pracę zespołu, tworzyć sztuczne problemy i marnować czas pracy, podczas gdy podejście hybrydowe czy funkcyjne pozwala osiągnąć ten sam rezultat szybciej i prościej.

Szczególnie na baczności powinni mieć się architekci i seniorzy, którzy mają największy wpływ na kierunek i sposób tworzenia oprogramowania. Do każdego zespołu prędzej czy później zapuka audytor. Wtedy nie będzie miało znaczenia, jak elegancko nazwano interfejsy, jak ortodoksyjnie przestrzegano zasad SOLID czy jak dobrze rozdzielono kod między modelem a kontrolerem. Liczyć się będzie, czy system da się rozwijać, zrozumieć i utrzymać w rozsądnym czasie oraz budżecie i czy przypadkiem w minionych latach nie przepalono firmowych pieniędzy na obiektowe rytuały.

OOP i antywzorce projektowe

Krytyka OOP ma silne podstawy. Przez lata programowanie obiektowe przestało być techniką, a stało się systemem wierzeń: każda funkcja musi mieć klasę, każda klasa interfejs, a jeśli coś trudno wyrazić obiektowo – winny jest programista, nie paradygmat. Fani OOP uwielbiają powtarzać, że „wystarczy dobrze zaprojektować architekturę”, po czym prezentują diagram klas przypominający mapę metra Tokio. Kod staje się nieczytelny? Rozwiązaniem jest… więcej abstrakcji, interfejsów i fabryk produkujących obiekty, które tworzą inne obiekty, by wywołać jedną funkcję.

Kult wzorców projektowych jest symptomem tej samej choroby. Większość wzorców to protezy języków obiektowych, które w innych paradygmatach w ogóle nie są potrzebne. Funkcje przekazywane jako parametry czy proste struktury danych eliminują większość hierarchii klas. A mimo to znajomość wzorców bywa traktowana jako dowód wyższości intelektualnej, zamiast sygnał problematycznego designu.

Warto pamiętać: jeśli kod działa i jest czytelny, wzorce w nim istnieją – tylko niekoniecznie te z podręczników trenerów OOP. Dojrzały inżynier nie pyta „jakie klasy stworzyć?” czy „jaki wzorzec tutaj użyć?”, lecz „jaki problem rozwiązuję i jak najprościej go zrealizować?”. Czasem odpowiedzią będzie OOP, częściej – coś innego. Fanatyzm wobec jednego paradygmatu to oznaka braku dojrzałości, a świat IT jest w ciągłym ruchu, idzie dalej, porzucając dogmaty i eksperymentując z prostszymi, skuteczniejszymi rozwiązaniami.

Ironia losu: Programiści PHP w pułapce spóźnionej nowoczesności

Programiści PHP przechodzą właśnie tragikomiczną drogę: gdy świat masowo odchodzi od OOP, oni zaadaptowali ten paradygmat na całego.

Przez lata język ten krytykowano za proceduralny bałagan. Pełne wsparcie dla obiektowości PHP otrzymało z dużym opóźnieniem, a społeczność – chcąc za wszelką cenę odciąć się od łatki amatorszczyzny – zaczęła bezkrytycznie implementować OOP i najbardziej złożone wzorce.

Dążenie do profesjonalizmu sprawiło, że projekty w PHP stały się karykaturą systemów korporacyjnych sprzed dwóch dekad. Poziom abstrakcji w typowej aplikacji Symfony jest wyższy niż w krytycznych systemach bankowych pisanych w nowoczesnych, nieobiektowych językach. Programiści PHP budują monumentalne konstrukcje tam, gdzie użytkownicy innych technologii stawiają na prostotę i bezpośrednie przetwarzanie danych.

Ten przypadek dopełnia tezę o zamknięciu w bańce informacyjnej. Środowisko PHP wydaje się nie zważać, że świat poza nimi porzucił ortodoksyjne OOP. Z uporem maniaka wciskają do kodu wszelkie dostępne wzorce projektowe, zasady SOLID, filozofie DDD i inne rytualne techniki, które w innych językach uznano za antywzorce i zbędny balast. To dlatego nowoczesny sektor IT nie sięga dziś po PHP. W środowisku tym brakuje nawet architektów i liderów, którzy byliby odporni na problem OOP.

Czego nigdy nie doświadczą fani OOP

Upór w forsowaniu programowania obiektowego jako jedynej „prawdziwej” drogi rozwoju ma swoją bardzo konkretną cenę: zawodową. Osoby które nie potrafią myśleć poza OOP, same zamykają sobie drzwi do ogromnej części realnego świata IT.

Nie trafią do zespołów budujących poważne systemy

W dużych firmach technologicznych, gdzie tworzone są systemy o realnym znaczeniu - sieciowe, chmurowe, bezpieczeństwa, kompilatory, silniki danych - nikt nie jest zainteresowany „czystością obiektową”. Liczy się rozwiązanie problemu, elastyczne myślenie, wydajność, stabilność i możliwość debugowania kodu pod presją. OOP jest tam balastem.

Nie dostaną również pracy przy systemach operacyjnych, sterownikach i niskopoziomowym kodzie. Systemy operacyjne, sterowniki, firmware, maszyny wirtualne - to świat, w którym królują języki nieobiektowe. Nie ma tam miejsca na klasy, fabryki i abstrakcje. Każda alokacja pamięci i każdy cykl procesora ma znaczenie, co wydajnościowo stoi w sprzeczności z podejściem OOP.

Nie odnajdą się w gamedevie

Gamedev jako miejsce pracy to marzenie wielu programistów. To również brutalna rzeczywistość: wydajność, cache, data-oriented design, iteracja w milisekundach. Klasyczne OOP ze swoimi hierarchiami i dziedziczonymi metodami jest tam jednym z pierwszych podejść, które się porzuca.

Dlatego silniki gier ewoluują od obiektów do danych, a nie odwrotnie. Fani OOP nie rozumieją tej zmiany i dlatego nie pracują przy silnikach, tylko przy formularzach webowych.

Nie zbudują konkurencyjnego startupu

Startup wygrywa czasem, prostotą i iteracją. Trzeba szybko sprawdzić hipotezę, zbudować MVP, zmienić kierunek, wyrzucić połowę kodu i zacząć od nowa. Kod OOP, pełen abstrakcji i „elastyczności na przyszłość”, doskonale nadaje się do… spowalniania tego procesu.

Zanim fan OOP zaprojektuje „docelową architekturę”, konkurencja uruchomi działające rozwiązanie, zbierze użytkowników i zdobędzie finansowanie.

Nie zrobią szybkiego i skutecznego proof-of-concept

Proof-of-concept ma być brzydki, szybki i często jednorazowy. Ma pokazać, że coś działa - nie że jest „ładnie zaprojektowane”. Osoby myślące wyłącznie obiektowo grzęzną na tym etapie w interfejsach, warstwach i wzorcach, zamiast po prostu napisać działający kod. Efekt? Po tygodniu nadal „projektują”, podczas gdy ktoś inny już testuje rozwiązanie na prawdziwych danych.

Zawsze będą pracować wolniej i rozwijać się węziej

Najpoważniejszą konsekwencją przywiązania do OOP jest zatrzymanie rozwoju. Jeśli wszystko widzisz jako obiekt, nigdy nie nauczysz się myślenia data-oriented, programowania funkcyjnego, pracy blisko sprzętu, projektowania systemów odpornych na awarie ani optymalizacji na poziomie, który ma realne znaczenie.

Programiści silnie przywiązani do OOP stają się specjalistami od jednego stylu kodowania, coraz mniej przydatnego w świecie, który idzie w zupełnie innym kierunku. Świat IT rozwijają ci, którzy odeszli od OOP w stronę alternatywnych i biznesowo weryfikowalnych technik.

OOP nie jest z gruntu złe

Programowanie obiektowe jest jednym z wielu narzędzi. Branża nie odchodzi od niego z braku zrozumienia, lecz dlatego, że OOP zawiodło tam, gdzie liczy się wydajność, przewidywalność i bezpieczeństwo. Sukces języków Rust, Go czy Swift, a także funkcyjnych nurtów w Javie i C++ to nie moda, a pragmatyczna odpowiedź na realne problemy, które obiektowość częściej maskowała, niż rozwiązywała.

W profesjonalnych projektach korzystających z OOP dominuje dziś podejście hybrydowe. Często zaledwie 10% kodu wykorzystuje OOP używane tam, gdzie naprawdę warto, podczas gdy pozostałe 90% stanowią czyste funkcje i potoki danych. Taki podział drastycznie ogranicza narzut architektury, ułatwia debugowanie i pozwala na szybszą iterację bez kodu tworzonego na wyrost.

„Programowanie obiektowe nie jest już takie jak kiedyś” - pisze Talin, jeden z blogerów w The Medium. „Zostało strącone z piedestału i rzadko można spotkać kogoś, kto by je propagował z takim religijnym zapałem, jaki można było obserwować dwadzieścia pięć lat temu” - dodaje.

Słowa te padły w 2018 roku, co znaczy, że autor ulokował szczyt popularności OOP w pierwszej połowie lat 90. Może będzie to dodatkową wskazówką dla niedowiarków, że czasy programowania obiektowego są już odległym wspomnieniem.

Mity

Na koniec kilka mitów do obalenia.

Mit: „Programowanie obiektowe jest standardem”

Nie jest. Jest jedną z wielu technik do wyboru i wcale nie dominującą. W językach stricte obiektowych jak Java i C++ obiektowość jest często tylko kontenerem na zwykłe funkcje.

Mit: „Duże projekty wymagają OOP”

To po prostu nieprawda. Największe i najbardziej krytyczne projekty świata - jądra systemów operacyjnych, serwery DNS, przeglądarki, infrastruktura sieciowa - przez dekady były i są pisane bez klasycznego OOP. Skala nie wymaga obiektów. Skala wymaga prostych zasad i kontroli nad złożonością.

Mit: „Bez OOP kod staje się spaghetti”

Spaghetti code nie bierze się z braku klas, tylko z braku dyscypliny. Proceduralny lub funkcyjny kod może być zarówno elegancki, jak i kompletnie nieczytelny - dokładnie tak samo jak kod obiektowy. Różnica polega na tym, że w OOP chaos bywa ukryty pod warstwami abstrakcji, co sprawia wrażenie porządku tam, gdzie go nie ma.

Mit: „OOP odwzorowuje rzeczywistość”

To jeden z najbardziej szkodliwych mitów. Programy nie odwzorowują rzeczywistości - one przetwarzają dane i wykonują operacje. Rzeczywistość nie ma klas, dziedziczenia ani interfejsów. To tylko metafory, które czasem pomagają, a czasem brutalnie zawodzą.

Większość problemów programistycznych to transformacje danych, a nie symulacje świata rzeczywistego. Próby wciskania wszystkiego w model „obiektów” często kończą się sztucznymi konstrukcjami, które istnieją tylko po to, by spełnić założenia paradygmatu.

Mit: „Każdy profesjonalny programista zna OOP”

Znajomość OOP to jedna z wielu technik - i właśnie dlatego nie jest to wyróżnik profesjonalizmu. Prawdziwym wyznacznikiem dojrzałości jest umiejętność wyboru paradygmatu adekwatnego do problemu oraz gotowość do porzucenia narzędzia, które przestaje być użyteczne. Programista, który zna tylko OOP i nie chce znać niczego więcej, nie jest ekspertem, lecz specjalistą od jednego młotka, który wszędzie widzi gwoździe.

Podsumowanie

• Programowanie obiektowe (OOP) nie jest dominującym paradygmatem w nowoczesnym IT i ustępuje podejściom funkcyjnym, proceduralnym oraz data-oriented.
• Wielu twórców i praktyków (m.in. Alan Kay, Joe Armstrong, John Carmack) krytykuje OOP za nadmiar abstrakcji, ukryty stan i niską przewidywalność systemów.
• W praktyce duże systemy (Google, Cloudflare, AWS, Meta i inne) coraz częściej opierają się na technologiach, które ograniczają klasyczne OOP na rzecz prostszych modeli danych i funkcji.
• Wydajność, kontrola pamięci i prostota architektury są często ważniejsze niż „czystość obiektowa” czy wzorce projektowe.
• Nadmiar OOP może prowadzić do przeregulowanych, trudnych w utrzymaniu systemów, gdzie złożoność wynika z samej architektury, a nie problemu biznesowego.
• Współczesna praktyka programistyczna jest hybrydowa: OOP bywa używane tylko tam, gdzie rzeczywiście ma sens, ale rdzeń systemów opiera się na funkcjach i danych.
• Na rozmowach o pracę w dużych firmach IT nikt nie pyta o znajomość OOP i SOLID, tylko o sposób poradzenia sobie z danym problemem.
• Najważniejsza kompetencja programisty to dobór paradygmatu do problemu, a nie trzymanie się jednego stylu jako uniwersalnego rozwiązania.