Objektumorientált szoftvertervezés - Vizsga, 2010.05.26.
A VIK Wikiből
OO Vizsga 2010-05-26
Egy szokásos "milyen értékek kerülnek perzisztálásra" feladat
(objektum különféle tagváltozóit módosítgatjuk, majd kiírjuk egy ObjectOutputStreamre, utána visszaolvassuk, ezután mennyi az egyes tagváltozók értéke).
A Netbeanses JPA-s autós példában milyen szerepet töltött be a Buffer? (Válaszát röviden indokolja)
- interfész
- servlet
- entity bean
- session bean
Két package adott volt, a függőségeik alapján Instability (RMI) számítása.
- RMI = CE / ( CA + CE )
- CA -> Az én packegemre mutató külső packagekből kiinduló kapcsolatok száma
- CE -> Az én packagemből kiindulú kapcsolatok száma külső packagekbe
- X/X+Y instability képlet ez kellett használni, ahol
- X a két package közt egyik irányban a függőségek száma,
- Y a két package közt másik irányban a függőségek száma.
Function Point elemzés fázisai.
Funkciópont elemzés (6. diasor/ 34 dia) komponensei:
- External Inputs
- External Outputs
- External Inquiries
- Internal Logical Files
- External Interface Files
Milyen táblákba képződik le a megadott struktúra (1 ős és két gyermekosztállyal) table-per-subclass leképezés esetén?
- Minden külön táblába, a 1 ős osztályban lesz discriminator, valamint a gyermek osztályokban lesz egy ID attribútum, ami az ősre mutat.
- Discriminator nem szükséges, diákon sem volt: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html#inheritance-tablepersubclass-discriminator
Strategized locking minta milyen problémát hogy old meg, UML class diagram.
- Probléma:
- a lock-olás beégetése a programba akadály:
- újrahasznosítás
- teljesítmény hangolás
- karbantartás
- a lock-olás beégetése a programba akadály:
- Megoldás:
- run-time delegálható szinkronizációs aspektus
- UML ábra -> diasor
Adott egy X osztály, ami aggregál egy Z osztályt, aki megvalósítja a Cloneable interfészt. Meg kell adni az X osztályra vonatkozó clone() függvényt, és garantálni kell, hogy az deep copy-t végezzen.
Object clone(){ A a3 = new A(); a3.b = b.clone(); return a3; }
Deadlock-hoz vezet-e az alábbi kódrészlet?
class A { synchronized void bar() { System.out.println("Deadlocked"); } } class B { private A a; public B() { a = new A(); } void foo() { synchronized(a) { a.bar(); } } }
- Nem, a pédányosítás során semmi szinkronizálandó dolog nem fut. De ha meghívjuk B foo() metódusát, akkor sem, mert ezek egymásba ágyazhatóak.
- A válasz az volt, hogy nem, a synchronized kulcsszó arra jó, hogy a szálat a szinkronizált kódrészlet erejéig garantáltan az adott objektum monitorában tartsa. Ha ezt kétszer adjuk ki, az nem okoz problémát, de nincs gyakorlati jelentősége sem. Viszont kiíródott, hogy "Deadlock".
synchronized 1. lehet blokk előtt - ekkor objektum referencia kell 2. metódus előtt - ekkor a monitor azé az objektumé, akin a metódust hívjuk - egyenértékű a teljes metódust felölelő blokkal
Mik a SAX alapvető jellemzői? (3p)
- Eseményvezérelt, callback (ContentHandler)
- Soros elérés (kis memóriaigény, nagy sebesség, nem lehet ugrálni a dokumnetumokban)
- Állapotfüggetlen feldolgozás
Milyen tervezési mintákat valósítanak meg? (5p)
- RMI stub - proxy
- TreeView node-jai - composite
- JPanel scrollbar - decorator
- Layout-kezelés - strategy
- AWT eseménykezelés - observer
A SwingWorkerre miért van szükség és kinek a felelőssége meghívni a process() és publish() metódusokat? (3p)
- Java -> Swing fejezet -> szálkezelés téma
- Mikor használjuk?
- hosszú I/O művelet, számítás stb. esetén -> különben nem reagál az alkalmazás
- Úgy viselkedik, mint egy szál
- párhuzamosan fut az eseménykezelővel,
- csak egyszer futtatható
- Visszatérési értéke van
- ez a futás végeztével elérhető
- tetszőleges típus lehet (genericitás)
- Képes kódot futtatni az eseménykezelő szálban
- hasznos, ha modellt kell módosítani
- process() és publish() metódusokat az eseménykezelő felelőssége meghívni
- publish()-t meghívod a doInBackground() metódusban, tehát NEM az eseménykezelőben, hanem a külön szálban és a SwingWorker megoldja, hogy az eseménykezelő szálból történjen egy process() hívás, ami tartalmaz egy vagy több publish()-nak átadott elemet (ilyenkor ezeket pl. hozzá lehet adni a GUIn egy listához, stb), itt egy példa: http://download.oracle.com/javase/6/docs/api/javax/swing/SwingWorker.html
Verziókezeléses módszerek, előnyei, hátrányai. Ha jól emlékszem, ez a kérdés a weave, delta, stb.-re kérdezett rá. CsL(3p)
- Írj a témáról amit jólesik, 3 pontért.
Reverse skip deltás példa. Mely revíziókat hogyan tároljuk el a 20., legutolsó revízióhoz képest? (3p)
A megoldás menete: minden új verziónál megnézzük, hogy hány záró 0 van a bináris alakjában, és hozzáadunk egyet, ennyi korábbi verzióhoz kell új deltát csinálni. Az újradeltázandó verziók a friss verzióból a 2 hatványok, de csak annyi, amit az előbb kiszámoltunk (x-1, x-2, x-4, x-8 ...)
A konkrét feladat megoldása(frisstől visszefelé a kapcsolatok):
- 20*:(19,18,16) *18*:(17) *16*:(15,14,12,8,0) *14*:(13) *12*:(11,10,4) *10*:(9) *8*:(7,6) *6*:(5) *4*:(3,2) *2*:(1)
A kulcsokat miért Set-ben, az értékeket miért Collection-ben adják vissza a Map interfészt megvalósító Java osztályok? (1p)
- Kulcsok - a kulcsokra érvényes az unicitás törvénye, azaz egyediséget biztosítanak, és egy értéktípusból egy szerepelhet. Ennek biztosításához egy halmaz-tulajdonságú adatszerkezet szükségeltetik, és a Set pontosan ilyen.
- Szerintem az is játszik, hogy a Setben nem lehet megváltoztatni az elemeket - ha ezt megtennénk, jól felborulna a kollekció belső adatszerkezete. CsL
- Értékek - egy-egy érték tetszőleges számban szerepelhet, így a Collection az (egyik) ideális adatszerkezet rá, ami ezt lehetővé teszi.
Avagy ezeket lehet változtatgatni. CsL
Choice(Identity, v) = ?
= Identity
-- keeroy - 2010.05.28.
-- CsL - 2010.05.28.
-- molnarm - 2010.05.29.
-- Eff - 2010.06.12.
-- Ciana - 2010.06.12.