1144-14. tétel Egy program fejlesztőjeként milyen érvekkel győzné meg a fejlesztő cégét, hogy objektum-orientált módszert használjon a strukturált helyett?

Információtartalom vázlata

–Szoftver architektúra kialakítása– UML, objektumok kommunikációja

–Adatszerkezetek, objektumok– Objektumok használatának előnyei

–Programtervezési módszerek– Objektumok újrahasznosítása– Polimorfizmus

–Felhasználói felületek– Template felületek– Öröklések előnyei

Objektumorinetált módszer strukturált helyett

Az objektumközpontú probléma megközelítés alapjaiban megváltoztatja a programozással kapcsolatos gondolkodásmódunkat. Az objektumorientált programozás alapja, hogy az adatokat és az őket kezelő függvényeket egy egységbe „zárjuk” (encapsulation – egységbezárás). Az OOP másik fontos sajátossága az öröklődés (inheritance). Az öröklés azt jelenti, hogy egy osztályból kiindulva újakat hozunk létre, amelyek öröklik az „ősosztály” (baseclass) adattagjait és metódusait. Az új osztályt származtatott (derived) osztálynak nevezzük

Objektumok kommunikációja Üzenetek

Hívó objektum által kért szolgáltatás UML

Grafikus jelölésekSzabvány

Szoftver architektúra Magas szintű terv A rendszert felépítő alrendszerek (szoftver komponensek) kerete

- • alrendszerek meghatározása- • alrendszerek tulajdonságai- • vezérlési, valamint kommunikációs kapcsolataik

A rendszer átfogó struktúrája- • több nézet -> több struktúra

Komponensek és összekötők összessége

A szoftver architektúra szerepe• Az érdekelt szereplők kommunikációjának lehetővé tétele• A korai fejlesztési fázisok döntéseinek támogatása a követelmények tükrében• Nagyléptékű újrafelhasználhatóság elősegítése

Helyesség: a specifikációnak megfelel- Hibatűrés: abnormális esetben is normálisan működik- Karbantarthatóság, bővíthetőség- Újrafelhasználhatóság- Kompatibilitás (belső/külső)- Felhasználóbarátság- Hordozhatóság (hardver/szoftver)- Hatékonyság (idő/hely)- Ellenőrizhetőség- Szabványosság

Ha egy programkódban objektumokról beszélünk, először az osztályok felépítését kell megvizsgálni, ugyanis minden objektum egy előre definiált osztály példánya. Egy osztályban általában egy feladat elvégzéséhez szükséges kódrészleteket gyűjtik össze funkciójuk szerint, tagfüggvényekbe rendezve. Egy osztályt létrehozása után példányosítani kell, hogy használhatóvá váljanak a benne összegyűjtött rutinok. Az osztály példányát nevezzük objektumnak.

Az objektumok kommunikációja Elvileg az objektumok üzeneteken keresztül kommunikálnak. Üzenetek

A hívó objektum által kért szolgáltatás neve; A szolgáltatás végrehajtásához szükséges információ másolata, valamint az eredmény tárolójának neve.

A gyakorlatban az üzenteket gyakran eljárás-hívással implementáljuk: Név = eljárás neve; Információ = paraméter-lista.

A Unified Modeling Language röviden UML, az objektumorientált programozás szabványos specifikációs nyelve. Az UML grafikus jelöléseket használ rendszerek absztrakt modelljének leírására. A szabvány UML jelölést használó diagramokat UML modelleknek nevezzük. Az UML az Object Management Group fejlesztése

Az UML (Unified Modeling Language) Az 1980-as és ‘90-es években számos jelölés-rendszert javasoltak az OO tervek

leírására. Az UML ezek egyesítéseként született. Az OO analízis és tervezés során használt számos modell leírási módját tartalmazza. Manapság ez az OO modellezés de facto szabványa.

Objektum: Információt tárol és kérésre feladatot hajt végre. Az objektum felelős a feladatainak korrekt elvégzéséért. Adatok (attribútomok)és metódusok (operációk, műveletek, azaz függvények, eljárások) összessége.(b) Az objektum állapota az adatok pillanatnyi értékei(c) Objektumorientált program: Egymással kommunikáló objektumok összessége, melyben minden objektumnak megvan a jól meghatározott feladata. (A "mit" az érdekes, nem a "hogyan".) A program a vezérlő objektum megszólításával indul (általában rögtön várakozik a felhasználóra).(d) Információ elrejtése: Az objektumokat CSAK üzeneteken keresztül kérhetjük meg a feladatok elvégzésére, csak ún. interfészen keresztül lehet kommunikálni vele. Az üzenet egy kívülről is elérhető metódus.

Ha egy programkódban objektumokról beszélünk, először az osztályok felépítését kell megvizsgálni, ugyanis minden objektum egy előre definiált osztály példánya. Egy osztályban általában egy feladat elvégzéséhez szükséges kódrészleteket gyűjtik össze funkciójuk szerint, tagfüggvényekbe rendezve. Egy osztályt létrehozása után példányosítani kell, hogy használhatóvá váljanak a benne összegyűjtött rutinok. Az osztály példányát nevezzük objektumnak.Ha egy programkódban objektumokról beszélünk, először az osztályok felépítését kell megvizsgálni, ugyanis minden objektum egy előre definiált osztály példánya. Egy osztályban általában egy feladat elvégzéséhez szükséges kódrészleteket gyűjtik össze funkciójuk szerint, tagfüggvényekbe rendezve. Egy osztályt létrehozása után példányosítani kell, hogy használhatóvá váljanak a benne összegyűjtött rutinok. Az osztály példányát nevezzük objektumnak.

Objektumok használatának előnyei Adatok+függvények=objektum Információ elrejtése Kötöttség csökkenthető Rugalmasabban átalakítható program

Az egységbezárás (encapsulation) azt jelenti, hogy a procedurális megközelítéssel ellentétben az adatok és a függvények a program nem különálló részét képezik, hanem azok egy egységes egészként jelennek meg, összetartoznak: együtt alkotnak egy objektumot. Az információ elrejtés (information hiding) azt jelenti, hogy az objektum felhasználójának nem kell tudnia arról, hogy az belsőleg hogyan működik, csak azt, hogy milyen funkcionalitást valósít meg, mi a felülete (interface).

Programozás szempontjából ennek több előnye is van az eljárás központú megközelítéssel szemben. Először is a különböző program részek közötti kötöttség lényegesen csökkenthető, és ennek biztosítására, kikényszerítésére nyelvi eszközöket is kapunk. Egy modul készítése esetén nem tudjuk elérni, hogy annak felhasználója esetleg nem megfelelő módon alkalmazza, ami inkonzisztens állapothoz vezethet. Egy objektum esetén (a PHP 5-ös verziójától kezdve) szabályozni tudjuk a benne lévő változók és metódusok láthatóságát, biztosítani tudjuk, hogy a programozó az objektumot csak annak felületén keresztül tudja

Polimorfizmus=Többrétűség• Adott tevékenység azonosítója közös• A végrehajtó függvény megvalósítása eltérő

Virtuális függvényKód újrafelhasználhatósága: Az osztályok.Polimorfizmus/többalakúság: Ugyanarra a kérelemre különböző objektumok különbözően reagálhatnak. Az üzenet küldőjének nem kell tudni a szerver osztályátÁltalánosítás: Több objektum leírásából kiemeljük a közös jellemzőket "mindegyik ugyanolyan lényegileg" (Osztály alkotás)Specializálás: Egy objektum leírásához egyedi jellemzőket adunk "olyan mint, de...." (Öröklés)

Felületek=Interfészek• Biztonsági segítség• Tartalmazza egy osztály felületét:

tagfüggvényeknyilvánossági tulajdonságokbemenő paraméterek

Objektum interfészek specifikációja Az objektumok interfészeit definiálni kell, hogy az objektumok és más komponensek

párhuzamosan fejleszthetők legyenek. A tervezés során el kell kerülni az interfész reprezentáció tervezését. Ezt az

objektumba kell rejteni. Az objektumoknak számos interfésze lehet, amelyek a szolgáltatott különféle

metódusokra jellemzőek. Az UML-ben osztály-diagramot használunk az interfészek specifikálására, de pl. a

Java nyelv is használható e célra.

A felületek, vagy más néven interfészek biztonsági segítséget jelentenek a nagyobb projektekben. Képzeljük csak el, mi történne, ha A objektum példányosításakor paraméterként átadunk neki egy másik, B objektumot, de B objektum nem valósítja meg hozzá fűzött reményeket, azaz nem tartalmaz egy változót, vagy függvényt, amire A osztálynak szüksége van! Az ilyen hibák felkutatása az OOP összetettsége miatt nem egyszerű, de az ilyen hibák felületek használatával elkerülhetőek.

A felület valójában előre meghatározza egy osztály felületét: Megadja a benne található tagfüggvényeket, azok nyilvánossági tulajdonságait, bemenő paramétereit, egyszóval a függvénytörzs kivételével mindent.

Az Objektum Orientált Tervezés

’70-től: Szoftverkrízis: a hagyományos módszer már alkalmatlan a jó szoftver fejlesztésére: paradigmaváltás (szemléletmód)(a) Strukturált szemlélet:A teljes feladat egy absztrakt utasításIdőbeli sorrendiség alapján történik a részekre bontásFelülről lefelé építkezikA szorosabban összetartozó adatelemek a folyamattól függetlenül csoportosíthatóak.Az adatcsoportok kezelése a programban szétszórva találhatóak.Legkisebb modulja az eljárás, melynek adatai elvesznek. globális változókat kell általában használni(b) Objektum orientált szemlélet:Objektumok üzenetei alkotják a programotNincs igazi időbeliségLentről felfelé építkezikAz adatokhoz kapcsoljuk az őket kezelő programrészeketLegkisebb modulja az objektum

A tervezési minták már némileg túl is mutatnak a kód újrahasznosításon, megoldás újrahasznosítást nyújtanak számunkra amennyiben OO módon programozunk. Ezek olyan

kész, kidolgozott receptek, melyeket adott problémák esetében bármikor bátran bevethetünk: ezek az adott feladatra jól bevált, kidolgozott megoldást nyújtanak. Egyik előnyük így adott is, ha felismerjük, hogy adott szituációban egyikük-másikuk használható, akkor egy komoly mankót, kész vázat kapunk az kezünkbe. Ezenkívül egy másik, nem annyira egyértelmű pluszt jelent az, hogy egy egységesen használható fogalom tárat is jelentenek, mely megkönnyíti a fejlesztők közötti kommunikációt

A Unified Modeling Language röviden UML, az objektumorientált programozás szabványos specifikációs nyelve. Az UML grafikus jelöléseket használ rendszerek absztrakt modelljének leírására. A szabvány UML jelölést használó diagramokat UML modelleknek nevezzük. Az UML az Object Management Group fejlesztéseAz UML (Unified Modeling Language) Az 1980-as és ‘90-es években számos jelölés-rendszert javasoltak az OO tervek leírására. Az UML ezek egyesítéseként született. Az OO analízis és tervezés során használt számos modell leírási módját tartalmazza. Manapság ez az OO modellezés de facto szabványa.

Az objektumok kommunikációja Elvileg az objektumok üzeneteken keresztül kommunikálnak. Üzenetek A hívó objektum által kért szolgáltatás neve; A szolgáltatás végrehajtásához szükséges információ másolata, valamint az eredmény

tárolójának neve. A gyakorlatban az üzenteket gyakran eljárás-hívással implementáljuk: Név = eljárás neve; Információ = paraméter-lista.

Az öröklés előnyei Egy absztrakciós mechanizmus, amely entitások osztályozására használható. Egy újrafelhasználási mechanizmus, amely a tervezés és programozás szintjén is használható. Az öröklési gráf alkalmazási környezetek és rendszerek szerveződéséről szolgáltat

információt.

Öröklődés előnyei• Meglevő osztályból új• Rendelkezik az ős minden tulajdonságával

Absztrakt osztály

Absztrakt osztályokkal alapvetően egy felületet definiálunk, amelyet a leszármazott

osztálynak meg kell valósítani. Ezt is elérhetnénk eljárás központú megközelítésben, de csak

úgy, hogy szövegesen dokumentáljuk, hogy egy adott felület megvalósításához milyen

függvényeket kell létrehoznunk, a mi felelősségünk, hogy ezt meg is tegyük. Absztrakt

osztály használatával ezt már fordítási időben ki tudjuk kényszeríteni. Nem megfelelő

implementáció esetén programunk le se fordul, tehát egy plusz nyelvi eszközt kapunk ennek

kikényszerítésére.

Osztály kibővítése

Ebben az esetben szeretnénk egy már meglévő funkcionalitást valamilyen szempontok alapján

kiegészíteni. Eljárás központú megközelítésben is tudunk egy már meglévő modulunkból egy

újat létrehozni, de ilyenkor az összes olyan függvényt, ami amúgy megfelelően működik, át

kell vezessünk az új modulban egy függvényen keresztül (vagy átnevezgetjük őket, de akkor

minden változtatás esetén külön figyelni kell arra, hogy a két modul konzisztens maradjon).

OOP esetben ezt sokkal egyszerűbben érjük el az öröklődéssel. Ilyenkor az új osztályban csak

azokat a függvényeket kell felüldefiniálni, amelyeknek a működése nem megfelelő

számunkra.

Egy osztály definiálása után előfordulhat, hogy az osztályban szereplő kódokat más osztályokban is használni szeretnénk. Például egy adatbázist, vagy mondjuk egy fájlkezelő függvényeket tartalmazó osztályt, valószínűleg más objektumokból is szeretnénk használni. Ehhez csak arra van szükség, hogy egy adott osztályt amiből a másik osztály tagfüggvényeit el akarjuk érni, abból származtassunk. Ezt nevezzük öröklődésnek

Az öröklés problémái Az objektum-osztályok nem „önjáróak”. A megértésükhöz szükséges a szuper-osztályuk

ismerete is. A tervezők gyakran újrahasznosítják az analízis során készített öröklési gráfot. Ez a

hatékonyság kárára válhat. Az analízis, tervezés és implementáció során használt öröklési gráfok célja más és más, ezeket

egymástól függetlenül kell kezelni.

Az öröklődés során származtatással hozunk létre egy már meglévő osztályból egy újat, amely

rendelkezni fog az ős minden tulajdonságával, és nekünk csak a kívánt plusz funkciókat kell

megvalósítanunk. A következő pontok ennek tipikus eseteit taglalják.

Tervezési modellek A tervezési modellek az objektumokat, objektum-osztályokat, valamint ezen entitások közötti

kapcsolatokat írják le. A statikus modellek a rendszer statikus struktúráját írják le objektum-osztályok és relációik

segítségével. A dinamikus modellek az objektumok közötti dinamikus interakciókat írják le.

Példák tervezési modellekre Alrendszer (sub-system) modellek, amelyek az objektumok koherens alrendszerekre való

logikus csoportosítását adják. A szekvencia-diagramok az objektumok közötti interakciók sorozatát írják le. Az állapotgép-modellek azt írják le, hogy az egyes objektumok hogyan változtatják

állapotukat eseményekre reagálva. Egyéb modellek: use-case modellek, aggregációs modellek, általánosítási modellek, stb...

Szekvencia-modellek Objektum interfészek specifikációja Az objektumok interfészeit definiálni kell, hogy az objektumok és más komponensek

párhuzamosan fejleszthetők legyenek. A tervezés során el kell kerülni az interfész reprezentáció tervezését. Ezt az objektumba kell

rejteni.

Az objektumoknak számos interfésze lehet, amelyek a szolgáltatott különféle metódusokra jellemzőek.

Az UML-ben osztály-diagramot használunk az interfészek specifikálására, de pl. a Java nyelv is használható e célra.