„Szoftverarchitektúrák - Jegyzet” változatai közötti eltérés
a Symunona átnevezte a(z) SzoftArArchitektúrák lapot a következő névre: Szoftver Architektúrák Jegyzet |
a linkkorrekció |
||
| 3. sor: | 3. sor: | ||
===I.1. Wrapper Facade=== | ===I.1. Wrapper Facade=== | ||
Nem OO API-k elé egy OO réteget húzunk, ami nyújt bizonyos szolgáltatásokat, ami felhasználja az alatta levő réteget. Így az alacsony szintű API helyett egy OO-sat hívunk, ez kényelmesebb és hordozhatóbb. Hátránya, hogy a funkcionalitás csökkenhet, valamint valószínűleg lassabb lesz a kód. | Nem OO API-k elé egy OO réteget húzunk, ami nyújt bizonyos szolgáltatásokat, ami felhasználja az alatta levő réteget. Így az alacsony szintű API helyett egy OO-sat hívunk, ez kényelmesebb és hordozhatóbb. Hátránya, hogy a funkcionalitás csökkenhet, valamint valószínűleg lassabb lesz a kód. | ||
===I.2. Component Configurator=== | ===I.2. Component Configurator=== | ||
Egy szolgáltatás interface-re több implementáció is létezhet, amelyek közül nem feltétlenül tudjuk kiválasztani fejlesztés közben a legjobbat. Ezzel a mintával elkészítjük az összes implementációt, és futási időben választjuk ki, hogy melyiket használjuk. A komponenseknek kell az életciklusukat kezelni, tehát elindítani és leállítani. Hátránya, hogy nem determinisztikus, valamint bonyolultabb lesz a kód. | Egy szolgáltatás interface-re több implementáció is létezhet, amelyek közül nem feltétlenül tudjuk kiválasztani fejlesztés közben a legjobbat. Ezzel a mintával elkészítjük az összes implementációt, és futási időben választjuk ki, hogy melyiket használjuk. A komponenseknek kell az életciklusukat kezelni, tehát elindítani és leállítani. Hátránya, hogy nem determinisztikus, valamint bonyolultabb lesz a kód. | ||
| 17. sor: | 15. sor: | ||
===I.3. Interceptor=== | ===I.3. Interceptor=== | ||
Az interceptor egy olyan eseménykezelő, amit a keretrendszer eseményeire lehet kötni. Hasonlít az AOP-hez. | Az interceptor egy olyan eseménykezelő, amit a keretrendszer eseményeire lehet kötni. Hasonlít az AOP-hez. | ||
| 29. sor: | 26. sor: | ||
===I.4. Extension Interface=== | ===I.4. Extension Interface=== | ||
Akkor jó, ha úgy kell kiterjeszteni egy osztályt, hogy a kliensen ne kelljen változtatni. Példakódhoz [http://stackoverflow.com/questions/1055833/need-citation-for-extension-interface-pattern-in-java lásd] | |||
Akkor jó, ha úgy kell kiterjeszteni egy osztályt, hogy a kliensen ne kelljen változtatni. Példakódhoz | |||
Szereplői: | Szereplői: | ||
| 40. sor: | 36. sor: | ||
==II. Eseménykezelési minták== | ==II. Eseménykezelési minták== | ||
===II.1. Reactor=== | ===II.1. Reactor=== | ||
[[OotTervezesiMintak#Reactor | Lásd.]] | |||
Szereplői: | Szereplői: | ||
| 53. sor: | 47. sor: | ||
===II.2. Proactor=== | ===II.2. Proactor=== | ||
A reactor aszinkron változata, híváskor a kezelőt aszinkron módon hívja meg, és amikor az visszatér, akkor kikeresi a kezelőt, amivel választ tud küldeni. | A reactor aszinkron változata, híváskor a kezelőt aszinkron módon hívja meg, és amikor az visszatér, akkor kikeresi a kezelőt, amivel választ tud küldeni. | ||
===II.3. Asynchronous Completion Token (ACT)=== | ===II.3. Asynchronous Completion Token (ACT)=== | ||
Mint a proactor, csak a választ kezelőt megkapja a feldolgozó, ezért nem kell kikeresni. [http://en.wikipedia.org/wiki/Proactor_pattern Leírás.] | |||
Mint a proactor, csak a választ kezelőt megkapja a feldolgozó, ezért nem kell kikeresni. | |||
===II.4. Acceptor-Connector=== | ===II.4. Acceptor-Connector=== | ||
| 68. sor: | 60. sor: | ||
==III. Konkurenciakezelési minták== | ==III. Konkurenciakezelési minták== | ||
===III.1. Active Object=== | ===III.1. Active Object=== | ||
[[OotTervezesiMintak#Akt_v_objektum | Lásd.]] | |||
===III.2. Monitor Object=== | ===III.2. Monitor Object=== | ||
[[OotTervezesiMintak#Monitor | Lásd.]] | |||
===III.3. Half-Sync/Half-Async=== | ===III.3. Half-Sync/Half-Async=== | ||
Lényege, hogy hardverfejlesztők aszinkron műveleteket szeretnek, szoftveresek meg szinkronokat. Ezzel a mintával megoldható, hogy mindenki úgy programozzon, ahogy szeretne. | Lényege, hogy hardverfejlesztők aszinkron műveleteket szeretnek, szoftveresek meg szinkronokat. Ezzel a mintával megoldható, hogy mindenki úgy programozzon, ahogy szeretne. | ||
| 88. sor: | 76. sor: | ||
===III.4. Leader/Followers=== | ===III.4. Leader/Followers=== | ||
[[OotTervezesiMintak#Vezet_k_vet | Lásd.]] | |||
==IV. Szinkronizációs tervezési minták== | ==IV. Szinkronizációs tervezési minták== | ||
===IV.1. Scoped Locking=== | ===IV.1. Scoped Locking=== | ||
Felhasználja, hogy a C++-ban amikor kilép a vezérlés az objektum scope-jából, akkor lefut a destruktora. Így a lock egy Guard osztály, aminek a konstruktorában lefoglalódik a zár, a destruktorában felszabadul. Így a zárolt részt bárhogyan hagyjuk el, biztosan nem marad zárolva. | Felhasználja, hogy a C++-ban amikor kilép a vezérlés az objektum scope-jából, akkor lefut a destruktora. Így a lock egy Guard osztály, aminek a konstruktorában lefoglalódik a zár, a destruktorában felszabadul. Így a zárolt részt bárhogyan hagyjuk el, biztosan nem marad zárolva. | ||
===IV.2. Strategized Locking=== | ===IV.2. Strategized Locking=== | ||
A lényege, hogy a lock objektumot paraméterként megadhatóvá tesszük, így a védett objektum létrehozásakor megadhatjuk, hogy milyen módon zárolható (R/W lock, mutex, stb...). Ehhez kell egy ősosztály, amiből a különböző implementációkat származtatjuk. | A lényege, hogy a lock objektumot paraméterként megadhatóvá tesszük, így a védett objektum létrehozásakor megadhatjuk, hogy milyen módon zárolható (R/W lock, mutex, stb...). Ehhez kell egy ősosztály, amiből a különböző implementációkat származtatjuk. | ||
===IV.3. Thread-Safe Interface=== | ===IV.3. Thread-Safe Interface=== | ||
A probléma az, hogy egy osztályon belüli metódushívásoknál többször is zárolni akar, akkor self-deadlock alakul ki. Ezért elválasztjuk a publikus metódusok hívását és az implementációjukat private metódusokba tesszük, és minden publikus metódus elején zárolunk, a többinél azonban nem. Így ha a függvények egymást hívják, nem lesz újrazárolás, viszont minden bejöbő hívás zárolt lesz. | A probléma az, hogy egy osztályon belüli metódushívásoknál többször is zárolni akar, akkor self-deadlock alakul ki. Ezért elválasztjuk a publikus metódusok hívását és az implementációjukat private metódusokba tesszük, és minden publikus metódus elején zárolunk, a többinél azonban nem. Így ha a függvények egymást hívják, nem lesz újrazárolás, viszont minden bejöbő hívás zárolt lesz. | ||
===IV.4. Double-Checked Locking Optimization=== | ===IV.4. Double-Checked Locking Optimization=== | ||
Ha egy kritikus szakasznak pontosan 1-szer szabad lefutnia, akkor zárolás után is meg kell győződnünk arról, hogy még nem futott-e le. Ez pl. Singletonok létrehozásánál lehet fontos, mivel a létrehozó fv-t több szál is meghívhatja egyszerre, ekkor ha csak záraink vannak, akkor egymás után több példányt is létrehoznak belőle. | Ha egy kritikus szakasznak pontosan 1-szer szabad lefutnia, akkor zárolás után is meg kell győződnünk arról, hogy még nem futott-e le. Ez pl. Singletonok létrehozásánál lehet fontos, mivel a létrehozó fv-t több szál is meghívhatja egyszerre, ekkor ha csak záraink vannak, akkor egymás után több példányt is létrehoznak belőle. | ||
| 126. sor: | 109. sor: | ||
-- [[SallaiTamas|sashee]] - 2010.10.16. | -- [[SallaiTamas|sashee]] - 2010.10.16. | ||
[[Category:InfoMsc]] | |||
[[Category: | |||