Osztályalapú programozás

A Wikipédiából, a szabad enciklopédiából

Az osztályalapú programozás, vagy általánosabban osztályorientált programozás, az objektumorientált programozásnak (OOP) egy stílusa, amelyben az öröklés az objektumok osztályainak meghatározása révén történik, ahelyett, hogy az öröklődés az objektumokon keresztül történne (összehasonlítva a prototípus-alapú programozással).

Az OOP legnépszerűbb és fejlesztett modellje egy osztályalapú model, egy objektumalapú model helyett. Ebben a modellben az objektumok entitások, amik kombinálják az állapotot (pl.: adat), viselkedést (pl.: eljárások vagy metódusok) és identitást (egyedi létezés az összes többi objektum között). Egy objektum szerkezete és viselkedése definiálva van egy osztály által, ami egy definícióval vagy egy tervrajzzal egy adott típusú objektum. Egy objektum kifejezetten egy osztály alapján kell létrehozni, és a létrehozott objektum az adott osztály példányának számít. Egy objektum hasonló egy szerkezethez, módszermutatók hozzáadásával, tag hozzáférés-vezérléssel, és egy implicit adattaggal, amely felkutatja az osztály példányait (pl.: az osztály példányai) az osztály-hierarchiájában (alapvető a futásidejű öröklési jellemzőknél).

Az objektumorientált programozás nem csupán osztályok és objektumok; ez egy egész programozási paradigma, amely az adatmezőket és módszereket tartalmazó objektumok (adatstruktúrák) köré épül. Elengedhetetlen ennek megértése; Az osztályok használata egy csomó nem kapcsolódó módszer együttes megszervezésére nem objektumorientáció.[1] Junade Ali, Mastering PHP Design Patterns

Egységbe zárás[szerkesztés]

Az egységbe zárás megakadályozza a felhasználókat attól, hogy megtörjék az osztály belső változóit, ami hasznos, mert ez megengedi az az objektumok osztályának implementációját, hogy megváltozzon az interfészen nem kitett szempontok esetén a felhasználói kód hatása nélkül. Az egységbe zárás definícióit arra fókuszálnak, hogy csoportosítsa és becsomagolja a kapcsolódó információkat (kohézió), mintsem a biztonsági problémák miatt. OOP-nyelvek általában nem kínálnak fel biztonsági megszorításokat az objektum belső állapota kapcsán. A hozzáférési módszer használata az interfész tervezésének szokásos kérdése.

Öröklődés[szerkesztés]

Fő cikk: Öröklődés (objektumorientált programozás)

Az osztályalapú programozásban az öröklődés elkészül egy új osztály definiálásával, amik kiterjesztései a meglévő osztályoknak: a meglévő osztály lesz a szülőosztály, és az új osztály lesz a gyermekosztály. Ha a gyermekosztálynak csak egy őse van, az akkor az egyszeres öröklődésként ismert, míg ha a gyermekosztálynak több mint egy ősosztálya van, akkor többszörös öröklődésként ismert. Ez az osztályokat egy hierarchiába szervezi, ami lehet egy fa (ha egyszeres öröklődés) vagy hálós (ha többszörös öröklődés).

Az öröklődés definiáló jellemzője az, hogy mind az interfész, mind az implementáció öröklődik: ha csak interfész öröklődik, akkor interfészöröklődésről vagy altípusról van szó. Öröklődés lehet osztályok nélkül is megtenni, ahogy az a prototípus-alapú programozásban látható.

Az osztályalapú modellek kritikája[szerkesztés]

Osztályalapú nyelvek vagy, hogy még pontosabb a gépelt nyelvek, ahol az alosztályok létrehozása az egyetlen út az altípusok létrehozásához, kritizálják, hogy összekeveri az implementációkat és az interfészeket - az alapvető alapelv az objektum-orientált programozásnak. A kritikák azt mondják, hogy létrehozható egy táska osztály, ami tárol egy objektumnyi kollekciót. Aztán ezt kibővítésre kerül egy új, készlet nevezetű osztállyal, ahol a objektumok duplikálását megszüntetjük.[2][3] Most egy olyan funkció, amely a táskaosztály objektumát veszi fel, számíthat arra, hogy két objektum hozzáadása kettővel megnöveli a táska méretét, mégis, ha az egyiket átadjuk a készlet osztálynak, akkor két objektum hozzáadása növelheti vagy nem növelheti a táska méretét kettővel. A probléma felmerül pontosan, mert egy alosztály altípust implikál, akkor is ha a példányokban, ahol az altípusok alapelve, ismertebb nevén Liskov helyettesítési elvet nem tartalmazza. Barbara Liskov és Jeannette Wing megalkották tömören az alapelvet egy 1994-es cikkben az alábbiak szerint:

Altípus követelménye: Legyen Φ(x) egy az objektumokról bizonyítható x T típusú, x tulajdonság. Ekkor Φ(y) értéknek igaznak kell lennie az S típusú y' objektumokra, ahol S altípusa T-nek.

Így általában meg kell különböztetni az altípust és az alosztályt. A legtöbb jelenlegi objektum-orientált nyelv megkülönbözteti az altípust és az alosztályokat, azonban a tervezés egyes megközelítései nem.

Továbbá egy másik gyakori példa, hogy egy gyermekosztályból létrehozott személy objektum nem válhat szülő osztály objektumává, mert a gyermek osztály és a szülő osztály örökli a személy osztályt, de az osztályon alapuló nyelvek többnyire nem teszik lehetővé az osztály típusának megváltoztatását az objektumnak futási időben. Osztályalapú nyelvek esetében ez a korlátozás elengedhetetlen annak érdekében, hogy megőrizzék a felhasználók egységes nézetét az osztályról. A felhasználóknak nem kell törődniük azzal, hogy a módszer egyik megvalósítása okoz-e olyan változásokat, amelyek megtörik az osztály belső változóit. Ilyen változtatások történhetnek az objektum megsemmisítésével és a helyére más építésével. A polimorfizmus felhasználható a releváns interfészek megőrzésére akkor is, ha ilyen változtatások történnek, mert az objektumokat feketedoboz-absztrakciónak tekintik, és objektumazonosságon keresztül érik el. Az objektumra hivatkozó objektumhivatkozások értéke azonban általában megváltozik, ami hatásokat okoz az ügyfélkódban.

Példanyelvek[szerkesztés]

Noha Simula bevezette az osztályabsztrakciót, az osztályalapú nyelv kanonikus példája a Smalltalk. Mások közé tartozik a PHP, a C ++, a Java, a C # és az Objective-C.

Kapcsolódó szócikkek[szerkesztés]

Jegyzetek[szerkesztés]

  1. Mastering PHP Design Patterns | PACKT Books, 1 (angol nyelven), Birmingham, England, UK: Packt Publishing Limited, 11. o.. ISBN 978-1-78588-713-0 
  2. Kiselyov, Oleg: Subtyping, Subclassing, and Trouble with OOP. (Hozzáférés: 2012. október 7.)
  3. Ducasse, Stéphane: A set cannot be a subtype of a bag. (Hozzáférés: 2012. október 7.)

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Class-based programming című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.