„Objektumorientált szoftvertervezés - Tervezési minták” változatai közötti eltérés
Új oldal, tartalma: „{{GlobalTemplate|Infoszak|OotTervezesiMintak}} __TOC__ ==9.1. Külső segédletek:== * {{InLineFileLink|Infoszak|OotTervezesiMintak|jegyzetPatternek_.pdf|Design_Pat…” |
Nincs szerkesztési összefoglaló |
||
1. sor: | 1. sor: | ||
__TOC__ | |||
==Külső segédletek:== | |||
[[Fájl:jegyzetPatternek_.pdf]] - néhány tervezési minta alaposabb kidolgozása | |||
[[Fájl:Szoftvertechnikak_Design_Patterns_16-17.pdf]] - Szoftvertechnikak_Design_Patterns_16-17.pdf | |||
== | ==Mintkák röviden== | ||
===Callback=== | ===Callback=== | ||
16. sor: | 14. sor: | ||
Mármint az első hívást ugye a kliens kezdeményezi, és utána ha esemény történik, akkor a szerepek megcserélődnek, és a szerver kezdeményez visszahívást a kliensek felé. | Mármint az első hívást ugye a kliens kezdeményezi, és utána ha esemény történik, akkor a szerepek megcserélődnek, és a szerver kezdeményez visszahívást a kliensek felé. | ||
callback.png | |||
===Factory=== | ===Factory=== | ||
23. sor: | 21. sor: | ||
A szerver minden egyes új hívásnál új példányt hoz létre a kiszolgáló servantból. | A szerver minden egyes új hívásnál új példányt hoz létre a kiszolgáló servantból. | ||
factory.png | |||
===Mobil ügynök=== | ===Mobil ügynök=== | ||
31. sor: | 29. sor: | ||
Lehet például arra használni, hogy elküldeni egy adatbázisnak, ott leszelektálja az eredményt, majd azzal visszajön, így ha valamit nem tudunk SQL-be megírni, akkor is csak minimális lesz a hálózati forgalom. | Lehet például arra használni, hogy elküldeni egy adatbázisnak, ott leszelektálja az eredményt, majd azzal visszajön, így ha valamit nem tudunk SQL-be megírni, akkor is csak minimális lesz a hálózati forgalom. | ||
mobileagent.png | |||
===Observer=== | ===Observer=== | ||
83. sor: | 81. sor: | ||
Hasonló, mint a Decorator, de ez nem ad plusz funkcionalitást az objektumhoz, csak elérhető/nem elérhetővé teszi azt. | Hasonló, mint a Decorator, de ez nem ad plusz funkcionalitást az objektumhoz, csak elérhető/nem elérhetővé teszi azt. | ||
== | ==Gyors összefoglaló== | ||
* Konténerek + komponensek -> Composite pattern | * Konténerek + komponensek -> Composite pattern |
A lap 2012. december 17., 22:05-kori változata
Külső segédletek:
Fájl:JegyzetPatternek .pdf - néhány tervezési minta alaposabb kidolgozása
Fájl:Szoftvertechnikak Design Patterns 16-17.pdf - Szoftvertechnikak_Design_Patterns_16-17.pdf
Mintkák röviden
Callback
Kliens és a szerver szerep felcserélődik, és a kliens hív vissza a szerverre
Mármint az első hívást ugye a kliens kezdeményezi, és utána ha esemény történik, akkor a szerepek megcserélődnek, és a szerver kezdeményez visszahívást a kliensek felé.
callback.png
Factory
Egy objektum hozza létre egy másik osztály példányait, inicializálja őket, és opcionálisan az életútjukat is követi. A szerver minden egyes új hívásnál új példányt hoz létre a kiszolgáló servantból.
factory.png
Mobil ügynök
Adat és kód egybezárva utazik rendszereken keresztül. Lényegében egy olyan programrész, amelyet az Agency-k futtatni tudnak, és tovább tudják adni.
Lehet például arra használni, hogy elküldeni egy adatbázisnak, ott leszelektálja az eredményt, majd azzal visszajön, így ha valamit nem tudunk SQL-be megírni, akkor is csak minimális lesz a hálózati forgalom.
mobileagent.png
Observer
A megfigyelt objektum az állapotában bekövetkezett változásokról értesíti a megfigyelőket.
Decorator
Egy objektum viselkedését futásidőben meg tudjuk változtatni. Létrehozunk egy Decorator-t, amely kiterjeszti a komponenst, majd konstruktorban kérjük el, és tároljuk is el. Ezután írjuk meg a függvényeit, melyek vagy egyből meghívják a komponens megfelelő függvényét, vagy írjuk át a kívánt módosított viselkedésre.
Whiteboard
Van egy központi Service Registry, ahova a figyelők, mint szolgáltatások regisztrálják magukat. Amikor jön egy event, akkor az összes illeszkedő service megkapja az eseményt.
Monitor
Szinkorizációs minta. Minden objektumnak van egy Monitor-ja, amelyet lehet birtokolni. Egyszerre csak 1 szál birtokolhatja, ha több is kéri, akkor várnia kell.
Aktív objektum
Az adott objektum függvényei aszinkron módon hívódnak meg, tehát hívásukkor a vezérlés visszatér, és a művelet egy várakozási sorba kerül. Amikor készen van, akkor egy callback történik (vagy visszakaphat rögtön egy változót, mondjuk egy Future-t). Szükséges hozzá egy Proxy, amely a hívásokat beteszi a sorba.
Reactor
Amikor egy szolgáltatást egyszerre több szál is hívja, akkor egyszerre mindig csak 1-et engedi hozzáférni, a többinek várakoznia kell. Ezáltal triviális lesz a konkurrencia kezelés, viszont a többszálúságból származó előnyök is elvesznek.
Vezető-követő
Egyszerre csak a leader figyel az eseményekre, a többiek várnak/feldolgoznak. Amikor jön egy esemény, más lesz a leader.
Visitor
A visitor egy olyan osztály, mely meg tud látogatni más osztályokat. Kell neki egy visit(..) metódusa, mely úgy van túlterhelve, amilyen osztályokat meg tud látogatni.
A meglátogatható osztályoknak kell egy accept(Visitor) metódusa, melyben visszahívják a visitor accept-jét magukkal. Így ha be akarunk járni egy fát, akkor a csomópontoknál az összes gyerekre meghívjuk az accept-et a visitorral.
Adaptable
Objektumok viselkedésének kiterjesztése anélkül, hogy módosítanánk az oszályt.
Szükséges hozzá egy IAdaptable interface, amiben van egy Object getAdapter(Class adapter) fv. Ez megkapja, hogy mivé szeretnénk kiegészíteni(adapter class-a), és létrehozza azt, majd visszaadja. A kiegészítendő osztályunknak ezt kell implementálnia.
A probléma ezzel az, hogy ha új kiegészítést akarunk felvenni(új fajta adapter), akkor módosítanunk kell az osztályt. Erre megoldás, ha létrehozunk egy IAdapterFactory-t és egy IAdapterManager-t(ez benne van az Eclipse-ben, szal ezt nem kell nekünk megírni), ahol az AdapterManager-be regisztálhatunk adaptereketé az AdapterFactoryból pedig a Object getAdapter(Object adaptableObject, Class adapterType) fv-n keresztül elkérhetjük a kiterjeszteni kívánt osztályhoz tartozó adaptert.
Strategy
Algoritmus runtime választható ki. Pl.: LayoutManager, beállítjuk az egyiket, és utána a kirajzolásnál annak az algoritmusa lesz használva.
Proxy
Hasonló, mint a Decorator, de ez nem ad plusz funkcionalitást az objektumhoz, csak elérhető/nem elérhetővé teszi azt.
Gyors összefoglaló
- Konténerek + komponensek -> Composite pattern
- Eseménykezelés, DocumentView architectúra -> Observer pattern
- LayoutManager -> Strategy pattern
- JScrollPane -> Decorator pattern
- JTree-nél Null Object pattern
- SortedSet -> Comparator pattern
- !Chatserver, SAX eseményvezérlése -> Callback pattern
- Bankfiók életciklus -> Factory pattern
- RMI stub, szövegszerkesztő -> Proxy pattern
- Beágyazott mobil Java ME eseménykezelője (registry miatt)-> Whiteboard pattern
-- sashee - 2009.05.19.
-- Velias - 2009.05.26.
-- Eff - 2010.06.12.