Az objektumorientált programozás lényege az, hogy a programozást nem a számítógép szemszögéből közelítjük meg, hanem a problémát objektumokká bontjuk, amelyeknek a viselkedését implementáljuk. Az objektumorientáltság a programozási nyelvek esetében nem konkrétan egy gondolkodásmódot jelent, hanem azt, hogy ennek megvalósítása céljából nyelvi elemek állnak rendelkezésre, amelyek révén a program elkészíthető. 

Az objektumorientált programozási nyelvek osztályokká és példányokká szabdalják a problémát. Tehát ha mondjuk valaki egy mozdony vezérlését egy objektumorientált nyelvben írja meg, akkor lesz egy osztály maga a vonat. A vonat osztályon belül lesz a mozdony osztálya, és lesz a kocsik osztálya. Lesz egy osztály a kerekeknek. Lesz egy példány a mozdonyból, mondjuk 5 példány a kocsikból, és mind a kocsik, mind a mozdony esetében lesz mondjuk 16 - vagy mittudomén hány - példány a kerékből.

A különböző osztályok nem csak a levegőben lógnak, hanem egymás részei lehetnek, amelyek interakcióba léphetnek egymással, tehát ha mondjuk elindul az adott kocsi - valamelyik kerék forgatását jelző függvény meghívódik - akkor ezt ilyen-olyan hackek segítségével az ajtó példányai is érzékelni tudják, és így az ajtó autómatikusan becsukódhat.

1. probléma: Az objektumorientált programozás pont, hogy a valóságot nem képes objektumokká képezni, tehát már arra sem jó, amire kitalálták

Mi történik akkor, ha a vonat lefékez? A folyamat a szerelvény egészére hat, de a mozdony logikailag a kocsikkal kb egy szinten van, mégis ki kell hatnia minden kocsira, a kerekekre, és a szerelvény egészére, tehát minden irányban. Ugyanez igaz arra, amikor valaki behúzza a vészféket. Látható, hogy a tárgyak interakciója sokrétűbb annál, hogy ezt halmaz-részhalmaz szerű logika alapján kapcsolatokká lehessen szervezni, így az egész koncepció megerőszakolása, és undorítóan ordas nagy hackek kellenek ahhoz, hogy osztályokká és objektumokká lehessen erőszakolni a feladatot.

2. A gépigény

Nem nehéz belátni, hogy ha objektumok láncolatává szerveztél valamit, amelyek egymással interakcióban vannak, akkor az horribilisen nagy overheadet tud jelenteni a gépigény tekintetében. Például ha csináltál egy vektor osztályt, amely autómatikusan kiszámítja a vektor normálvektorát és hosszát, az pont tizedelni fogja az algoritmus sebességét, lehet, hogy feleslegesen, mert neked a normálvektora mondjuk csak az egész kódban 2 helyen kell, de mondjuk a vektor iránya több ezer helyen, sebességkritikus részeken. A megoldás kézenfekvő: nem kell mindig kiszámolni a normálvektort, csak ha szűkséges. Tehát létrehoztál egy objektumot, amely vagy nem fog objektumként viselkedni többé, vagy 50 fps helyett lesz 5 fps a játékod...

3. A munkamorál

A sok különböző osztályt egyszerűen szét lehet bontani fájlokra, egy nagyvállalat számára tehát ez akár még egy ideális szervezőerő is lehet. Minden osztály és objektum fejlesztését le lehet osztani a különböző kollegákra. Persze ezt OOP nélkül is meg lehet tenni. OOP-vel viszont lehet úgy dolgozni, hogy nem dolgozol. Gépelgeted az osztályokat, akár több ezret is létrehozol belőle, gyönyörűen osztályokká bontottál egy egész problémát, hónapok alatt azon dolgoztál, hogy mondjuk egy csomagküldőszolgálat működését hogyan objektumizáld. Majd amikor valaki megkérdezi, hogy hol tartasz, már büffentheted is neki oda, hogy nézd már, mennyi kód van, amely megyénként osztályba szervezi a futárokat, a járműveiket, a javíttatásukat, a megrendelőket, az ügyfeleket, a grafikus felület vezérlését, a loginrendszert. Tulajdonképpen már majdnem minden kész van, csak még egyvalamit nem kezdtél el megcsinálni: a programot, amit ennyi idő alatt akár meg is írhattál volna. Hisz akár egy 7. osztályos diák is megírta volna basicben házi feladatként egy hétvége alatt, de neked mostmár 10 alkalmazott is kelleni fog hozzá, meg egy jó fél év, hogy legyen is belőle valami, aztán kvadozás után a tábortűznél lehet róla anekdotázni, hogy te mekkora fejlesztőzsuga vagy, nagyon komoly munkát végzel egy nagyon komoly nagyvállalatnál a többi 10 idiótával együtt, akik ideológiailag bevédik egymás seggét azt az impressziót keltve, hogy tulajdonképpen dolgoznak akkor, amikor valaki megkérdezi, hogy tulajdonképpen mi a kurva anyátokat is csináltok ti itt? Önmagában persze az objektumorienált programozás még nem feltétlenül kéne, hogy tönkretegyen egy projektet, hisz ha így lenne, akkor kihalt volna az egész. De a programozást mégis általában produktivitás nélküli tevékenységgé silányítja, ami utat nyitva az áltudományos megszakértgetés felé a költségek végére 2-3 nullát ír. Érdekes módon aztán a komoly munkákban, vagy az adott szoftver komoly részeiben objektumorientált programozásnak aztán nyoma sincs. 

4. Tehát lehetne jól is használni az objektumorientált programozást, de az emberek mégsem jól használják.

Régebben néha előfordult, hogy ha volt egy olyan ismerősöm, aki valamihez jobban ért, mint én, akkor megkértem, hogy írja meg helyettem ezt-azt a problémát, cserébe mondjuk segítettem neki a hibákat javítani, vagy tesztelni segítettem, esetleg tanácsokkal szolgáltam neki az ilyen-olyan dolgok implementálásához. Ezek mindig egyszerű problémák voltak, de előfordult, hogy ezek az emberek objektumorientált kódot adtak és a néhány órás munka helyett hetekig kotlottak rajta, hogy a végén sík ideg arccal odaadják, hogy tessék, itt van a szarod. Hát mondom, ember, mi történt? Nézem a kódot, és az érdemi része kb 300 sor. A körülötte lévő objektumgyűrű pedig 4000, és minden 3.-4. meghívás után segfaultol a program. Ez nem túlzás, és nem vicc, ez egy fájlformátum betöltője volt, amely annyit csinált, hogy a chunkok alapján fseekelt, és betöltötte az adatokat. A kód pár száz kilobájtos fájlokon 3-4 másodpercig dolgozott, az eredményeket kb olyan szintaktikával kellett kiszedni, hogy object->loader->vtx->chunk1.data.xyz(id).xyz1[k] és annyira bugos volt, hogy egy idő után inkább egyszerűen megírtam C-ben, ami 2 órát emésztett fel az életemből, és lett 300-400 sor, a működése pedig szám szerint 200x lett gyorsabb. Az emberek 99%-a tehát ótvar szarul használja az OOP-t, tulajdonképpen általában minnél inkább vergődik valaki az OOP elvek mellett, annál inkább nem érti, meg annál inkább nem tudja használni, meg annál inkább nem tud programozni.

5. Az objektumorientált programozás célja a kód átláthatóságának és egyszerűségének növelése lenne

Mi a halál bágyadt fasza ez?

És ez az, amire az OOP képtelen. Ennek ellenére ma már az objektumorientált programozást lehetévő tevő, vagy ennek kizárólagosságát hirdető nyelvek vannak többségben, mert egész egyszerűen a nagyvállalati kóklerprogramozók ebben szeretnének dolgokat megszakértgetni bármiféle valódi munka, hozzáértés, vagy tudás nélkül, és azt akarják, hogy őket a valódi programozók a munkájukkal eltartsák - miközben ők pedig a program felesleges, obskúrus rétegeinek megszakértésével büffentgetnek, majd egymás pozícióba szopkodása után gargalizálnak.

Összességében tehát objektumorientált kódot manapság olyan projekteknél használnak, ahol nincs hozzáértő ember, ahol nincs szűkség valódi programozási munkára, ahol feltétel az, hogy a projekt SOHA SE készüljön el, drága legyen, lassú legyen, az indokoltnál tízszer több ember kelljen hozzá, tízszer akkora legyen, mint indokolt, sokáig tartson elkészíteni, ne legyen átlátható, ne legyen érdemben továbbfejleszthető, sokat lehessen kérni érte, miközben a programozói munkát igénylő feladatok esetén (pl linux kernel, titkosítóalgoritmusok, stb) mindenkit azonnal kivágnak, aki oop kódot próbál beleszakérteni a forrásba, ugyanis van, ahol egy programozói munkát tényleg programozóknak kell elvégezni.

Az OOP tulajdonképpen a szoftverfejlesztés liberalizmusa, és azt üzeni, hogy nem kell érteni semmihez, elég, ha írsz egy ügyes osztályt, és akár még megszakértő manager is lehet belőled egy nagyon komoly európai nagyvállalat pincéjében. Persze OOP-s nyelvekben is vannak jó programozók, akik ténylegesen is dolgoznak, csak mondjuk relatíve elég kevés, míg a C-sek közül általában a negyede képes rendes munkát végezni, addig az OOP-s nyelvekben ez az arány 1% sincs.