IRT Illy és László

1. IRTIllyés László 7. kurzus Az objektum-orientált tervezés alapelemei

2. Az objektum fogalma • A programozói gyakorlat a következő cél megfogalmazásához vezetett: egy objektumra vonatkozó minden információ a program egyetlen helyén jelenjen meg. • Adatszerkezet és algoritmus egy helyen • Ez az információ a program többi részében, sőt más programokban is könnyen újrahasználható legyen • Szisztematikus programfejlesztés során tudatosult, hogy az információ-feldolgozási probléma megközelíthető az adatok és az algoritmusok oldaláról

3. Az objektumorientált paradigma • Paradigmának nevezzük egy világszemlélet, látás és gondolkodásmódot, amelyet az adott fogalomkörben használt elméletek, modellek és módszerek összessége jellemez. • Az objektumorientáltság egy paradigma, amelynek alapján több rendszerfejlesztési módszertant is kidolgoztak. Ezek a módszertanok a modellezéstől az implementációig sőt a karbantartásig átfogják a teljes fejlesztési folyamatot. Az a rendszer, amelynek fejlesztésére, leírására a módszertanok használhatók, értelmezhető a szoftver rendszernél lényegesen tágabban is, jelenthet egy integrált hardver-szoftver együttest vagy egy szervezetet is.

4. Az objektumorientált módszertan • Az objektumorientált módszertan alkalmazásával a kifejlesztendő rendszert együttműködő objektumokkal modellezzük, a tervezés és az implementáció során pedig ezen objektumokat "szimuláló" programegységeket alakítunk ki. • A minket körülvevő világ olyan objektumokkal írható le, mint házak, városok, emberek, járművek stb. Ugyanezen világ jellemezhető olyan objektumokkal is mint napközi, iskola, egyetem, diák, tanár. A modell objektumait az határozza meg, hogy a rendszer milyen vonatkozásait akarjuk megjeleníteni, az objektum modell a valóság mely szeletét reprezentálja. Az objektumok valamilyen absztrakciót tükröznek.

5. Az objektum • − Az objektum egy valós vagy absztrakt, azonosítható, egyedi entitás, amely a vizsgált környezet egy jól definiált szereplője. • − Egy objektum más objektumokra hatást gyakorol és más objektumok hatással vannak rá. • − Objektumként definiálható bármi, aminek pontos határai meghúzhatók. • − Az objektum jellemezhető a rajta értelmezett műveletekkel és a rajta elvégzett műveletek hatását rögzítő állapottal.

6. Az objektum definíciója • Az objektum egy rendszer egyedileg azonosítható szereplője, amelyet a külvilág felé mutatott viselkedésével, belső struktúrájával és állapotával jellemezhetünk. • Egységbe zárás (encapsulation) azt jelenti, hogy egy objektum egységbe zárja az állapotát tartalmazó adatstruktúrát, a rajtuk végrehajtott műveleteket. Az objektum tervezőjének a feladata a struktúra, viselkedés és állapotok programozása. A külvilág (külső program) az objektum szolgáltatásait veszi igénybe.

7. Az objektum felelőssége • Minden objektum felelős önmagáért • Az objektumhoz felelősség rendelhető, amelynek vállalása és teljesítése az objektum feladata

8. Az objektum viselkedése • Az általa végrehajtott tevékenységsorozatban nyilvánul meg. • aktív • passzív • Aktív: folyamatosan működik, valamilyen tevékenységet hajt végre, más objektumokra hatást gyakorol. (főprogram, vezérlő-objektum) • Passzív: addíg nem tesz semmit, amíg valamilyen külső hatás nem éri (esemény, üzenet) (pl. daemon)

9. Üzenetek • Az objektumok egymásra hatása az üzeneteken keresztül valósul meg. • Az üzenetek továbbításához “infrastruktúra” szükségeltetik • Az üzenet szerepe: • vezérlési szerep • adatcsere az objektumok között • az üzenet komponensei: • név • paraméter

10. Üzenetek küldése • Egy adott nevű üzenet többször is elküldhető más-más vagy ugyanazon paraméterekkel • Egy objektum több, különböző nevű üzenet fogadására képes. Ezek sorrendje is fontos lehet az objektum számára • Azonos nevű, különböző paraméterekkel kapott üzenet az objektum azonos reakcióit idézik elő, amelyik folytatása függhet a paraméter értelmezésétől • A paraméter más objektum is lehet.

11. Üzenetek-komolyabban • Aki kapja tudja-e (kell-e tudnia), hogy az üzenetet kitől kapta, képes-e szelektíven fogadni • Konkurens objektumok problémái: • Indulhat-e a rendszer eleve több aktív objektummal? • Létezhetnek-e aszinkron műveletek • Objektumon belüli konkurencia lehetséges-e? (az objektum még nem dolgozta fel az előző üzenetet, amikor újabb üzenetet kap, amelyik esetleg teljesen más viselkedésre ösztönzik)

12. Események (event) • Egyes módszertanok az üzenet helyett az esemény fogalmát vezetik be az objektumok közötti kölcsönhatás modellezésénél. • Az esemény egy azonosítható, pillanatszerű történés • Az eseményekhez statikus (név) és dinamikus (paraméter) információk tartozhatnak • Az eseményeket az objektumok hozzák létre (objektum lehet a felhasználó is, mint aktor) • Felmerülő kérdések: • van-e címzettje az eseménynek • eldöntheti-e az objektum, hogy melyik eseményre reagáljon • egy eseményre egyetlen objektum reagál-e vagy több

13. Üzenet és esemény • Az együttes használat sokszor egyértelmű • Ha egy objektum észlel egy eseményt, majd erről üzenetküldéssel értesít egy másik objektumot, a számára az üzenet is lehet egy esemény • Pl.: Ha van egy szenzorunk, amelyik egy gépnél a maximális lehetséges elmozdulást jelzi, az általa küldött üzenet egy olyan esemény a vezérlőegység számára, amelyik gép leállására vagy a mozgásirány megváltoztatására kényszeríti • Az üres üzenet is tartalmazhat kódolt információt

14. Metódusok (operációk) • Üzenet hatására az objektumok végrehajtják a hozzájuk rendelt felelősségek által meghatározott cselekedeteket. • Ezen cselekedeteket metódusoknak vagy operációknak nevezzük • Az objektum viselkedésének meghatározása a metódusokba van belekódolva • Üzenet: MIT, metódus: HOGYAN • Ugyanaz az objektum ugyanarra az üzenetre (ugyanolyan paraméter értékekkel) másképp is reagálhat, a korábbi hatásoktól függően

15. Ugyanannak az objekumnak 2 ugyanolyan egymásutáni eseméyre való regálása hozzaAd(6) hozzaAd(11)

16. A hozzaAd(ertek:int) megvalósítása Public void hozzaAd(int ertek){ S=S+ertek; } Az objektum állapot minden üzenetre változik. (Változik az S attribútum értéke) Rövidített változata az értékadásnak S+=ertek;

17. Üzenetek, események és metódusok • Ezek alkotják az osztály felelősségét és az osztály jelölésében a 3-ik részt foglalják el • Lehetnek: • Üres üzenet • Paraméterezett üzenet • Üres üzenet visszatérési értékkel • Paraméterezett üzenet visszatérési értékkel

18. Állapotok • Az objektum azonos tartalmú üzenetre különbözőképpen reagálhat • Pl. A felvonó attól függően indul el felfele vagy lefele, hogy a hívó személy milyen relatív pozícióban van hozzá képest • Az objektumban végbemenő változások nyomát az objektum állapota jellemzi. • Az objektum állapotát az attribútumok tárolják. Az attribútumok értékei változhatnak az objektum életciklusa során

19. Objektumok létehozása, inicializálása Az objektumnak életciklusa van. Megszületik, él és meghal. Születéskor meg kell adni a kezdeti adatait. Az inicializálást végző metódust konstruktornak nevezzük. Egy osztálynak lehet több konstruktora is. Javaban az objektumot a new(új) operátoral hozzuk létre. Az operátor után meg kell adni az osztály nevét. Mivel a konstruktor neve egyben az osztály neve is, az objektum automatikusan inicializálódik.

20. Egy osztálynak több konstruktora Egy ablak a képernyőn megadható többféle képpen. • A bal felső sarok helyzete a képernyőn +szélesség+magasság • A bal felső sarok helyzete + jobb alsó sarok helyzete Pont(x:int, y:int){} Ablak(balFelsoPont:Pont, szelesseg:int, magassag:int){} Ablak(balFelsoPont:Pont, jobbAlsoPont:Pont){}

22. A főprogram üzenetei • Keletkezik 2 új pont objektumunk • pont P1=new pont(2.2,3.3); • pont P2=new pont(2.2,6.3); • Keletkezik egy új szakasz objektumunk a 2 létező ponttal • szakasz szk=new szakasz(P1,P2); • Kiíratjuk a szakasz hosszát • System.out.println("szakasz hossza="+szk.mennyiaHossza());

23. A metódus megvalósítása public double mennyiaHossza() { return Math.sqrt(Math.pow((kezdoPont.getYKoord()-vegPont.getYKoord()),2) +Math.pow((kezdoPont.getXKoord()-vegPont.getXKoord()),2)); } Ez a metódus elkéri a kezdőpont és a végpont koordinátáit (üzenet válasszal-get), amely alapján kiszámítható a szakasz hossza.

24. Osztályok és példányok (objektumok) • Megegyező viselkedésű és struktúrájú objektumok egy közös minta alapján készülnek, amit osztálynak nevezünk. • Az osztály a megegyező viselkedésű és struktúrájú objektumok gyára, vagy forrása • Az objektum az osztály egy pédánya (instance) • Az objektum egy bizonyos pillanatban létező egyed. Minden objektum különbözik a másik, ugyanazon osztályból származó objektumtól- equals – ki kivel egyenlő • Az objektum ismeri az osztályt, amelyikből származik

25. Osztályok és objektumok A kutya osztály A kutya osztály egy példánya, kutya neve Néró (objektum) A kutya osztály egy másik példánya, kutya neve Beethoven (objektum) A kutya osztály egy általános példánya (objektuma) név nem ismert vagy nem jellemző

26. Az információ-elrejtés elve • Az objektumok más objektumok által csak a metódusokon keresztül érhetők el. • Lehetnek belső metódusok, amelyek a működés egy részét is elrejtik (függvényhívás) • A publikus metódusokat nevezhetjük az osztály szolgáltatásainak is, azokon keresztül valósul meg az objektum felelőssége

27. A Demeter törvény (az objektum és környezete közötti csatolás gyengítésének elve) • A csatolás a leggyengébb, ha a metóduson belül csak az alábbi elemekre történik hivatkozás: • A metódus paramétereire és eredményére • A metódust tartalmazó osztály attribútumaira • A program globális változóira • A metódusban definiált lokális változókra

28. CRC kártyák (Class-Responsibility-Collaboration) • Osztály-Felelősség-Együttműködés kártyák • Egy brainstorming eszköz, amelyik az objektum-orientált szoftver tervezésében használnak • Ward Cunningham javasolta • Index kártyákból készítették (76x127mm) • ISO mérete az A7-es. • Tartalma: • az osztály neve • a szuper- és alosztályok (ha léteznek) • az osztály felelősségei • azon osztályok, amelyekkel együttműködik • a szerző

29. Osztály-felelősség-együttműködés • Kis kártyák használata a tervezés komplexitását csökkenti. Ráirányítja a tervező figyelmét az osztály lényegére és eltávolítja a túlzott részletességtől. • Kényszeríti a tervezőt, hogy ne adjon túl sok felelősséget egy osztálynak • Mivel hordozható, elhelyezhető egy táblán, s újra rendezhető a tervezés folyamán • A legbanálisabb módszer: olvasva a követelmény-specifikációt, kiválasztjuk a főneveket, mint lehetséges osztályokat vagy attribútumokat és az igéket, mint lehetséges felelősségeket