Mi az objektumorientált programozás lényege?

#20: OK. Be kell vallanom, hogy a Turbó pacalnál maradtam le a programozásban a boldog 90-es években, azóta főleg Visual Basicban dekorálok objektumokat eseményekkel, amikor muszáj.

Így a személyes élményem az, hogy manapság a programozók előre megírt objektumokat dekorálnak, pl. egy Excel tábla mezőit, de készséggel elfogadom, hogy a személyes élményem nem minden...

21

Valóban, ez valami hobbi programozás lehet, az excel meg eleve nem programozás. A programozók az osztályokat is maguk írják (meg használnak is fel persze).

De eleve, az objektum orientált programozás az több, mint annyi, hogy van benne objektum: vannak osztályok (ezek példányai az objektumok), ezek egymást tartalmazhatják, öröklési hierarchiában vannak, interfészek vannak, stb.

21: Azért a Visual Basic cuccaimmal már sikerült profikat is meglepnem, de rendben, persze, valóban a saját problémáim indítanak programozásra, tehát amatőr vagyok.

A kérdés úgy szólt, mi az objektumorientált programozás lényege, ez lehet matematikai lényeg (azt nem értem), vagy lehet munkaszervezési lényeg, utóbbi szempontból úgy látom, hogy a programozói csapatmunka szervezésének egyik megközelítése.

23

Az objektumorientált programozás egy paradigma, nem csapatszervezés. Ez a forráskód alapvető tervezését befolyásolja, majd végig megy az implementáláson (szóval ilyen szempontból persze ráhat a csapatszervezésre is)

25

Hogy átláthatóbb legyen a kód, újrafelhasználhatóbb. Nem mindig kell persze ezt használni, de sokszor jól jön

Az OOP egyik legnagyobb előnye más paradigmákhoz képest, hogy valamivel közelebb áll ahhoz, ahogyan a hétköznapokban kezeljük a dolgainkat. Mire gondolok? Tárgyaink vannak, ezeknek a tárgyaknak tulajdonságaik és funkcióik vannak. Vannak absztrakt fogalmaink is, amik ehhez hasonlóak kezelhetőek, például jógacsoport, iskola, és így tovább. Ezek mind-mind tulajdonságokkal és funkciókkal bírnak, amelyek a sajátjaik, és interakciókba lépnek egymással - például a hétvégi jógát az iskola tornatermében tartják.

Az OOP segítségével könnyebben megfoghatóak a problémák, mert a hétköznapi gondolkodáshoz közelebb álló modellt tudunk alkotni. Az egységbezárás alapelve például pont azt írja le, hogy egy objektum tulajdonságai és funkciói egy egységet kell alkossanak.

Ahogy a valóságban, az OOP-ben is megjelenik az általánosítás az öröklődésen keresztül. Lehet egy iskola osztályom, abból specializálhatok általános iskolát, amiből pedig... Nos, már példányosítok egy Petőfi Sándor Általános iskola objektumot. Ez az öröklődés: a specializált gyermekosztályok öröklik (és sok esetben pontosítják) az általános ősosztályok tulajdonságait és funkcióit.

Ebből fakadóan jelenik meg a sokoldalúság is: ha van egy "jármű", ami "megy", az úgy általában elég. Megy a vonat, a hajó, az autó, a repülő. A specializált változatok definiálják, hogy pontosan mit jelent, ha megy egy vonat, hajó, repülő vagy autó. A "megy" sokféle tartalma maga a polimorfizmus.

Az OOP egy nagyon frankó paradigma, de csak egy bizonyos méret és komplexitás felett. Az OOP elveket betartó kódbázis általában rugalmasabban fejleszthető összehasonlítva más paradigmákkal. Fontos minőségbiztosítási aspektus, hogy a jól felépített OOP kód fölé viszonylag könnyen lehet ún. unit teszteket fejleszteni, amik növelik a kódbázis nem várt mellékhatásokkal szembeni ellenállóságát. A számtalan kvázi-szabványos mintának, illetve az egymáshoz lazán kapcsolódó objektumoknak köszönhetően a kollaboráció is könnyebben menedzselhető.

Léteznek, de az OOP a lekényelmesebb.

Procedurálisan is meg lehet írni bármit, csak egy bizonyos méret, egy összetettség felett már gazdaságtalan.

A megrendelő egyszerűen nem fizetné ki. Egy sok-sok millió dolláros űrprojekt esetében persze kifizeti, mert hosszabb távon így gazdaságosabb, jobb, több a hozadék, de a földi market (piac) nem így rezonál.

Ezért van az, hogy a tervezésre/kódolásra fordított idő lerövidül, de a silány, vagy a lehetségesnél gyengébb szoftver erőforrásigényesebb lesz, ezért a dolog áttolódik a tervezőasztalról a gyakorlati felhasználás területére. A kliens/szerver apparátus fogja elviselni a töbletterhet, amit most még át lehet pakolni a másik térfélre, csak kérdéses, hogy meddig.

#28 - Ahogy a #29-es is írja, ma az OOP a legelterjedtebb. Még az olyan, eredetileg nem OOP nyelvek is próbálnak OOP irányba fejlődni, mint a PHP vagy a JavaScript.

Ugyanakkor pl. a Linux kernel procedurális paradigma szerint épül fel (bár vannak olyan részei, ahol OOP-t alkalmaznak)