„Objektumorientált szoftvertervezés - Tervezési minták” változatai közötti eltérés
Nincs szerkesztési összefoglaló |
Nincs szerkesztési összefoglaló |
||
14. 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 | [[Fájl:callback.png]] | ||
===Factory=== | ===Factory=== | ||
21. 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 | [[Fájl:factory.png]] | ||
===Mobil ügynök=== | ===Mobil ügynök=== | ||
29. 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 | [[Fájl:mobileagent.png]] | ||
===Observer=== | ===Observer=== | ||
69. sor: | 70. sor: | ||
Objektumok viselkedésének kiterjesztése anélkül, hogy módosítanánk az oszályt. | Objektumok viselkedésének kiterjesztése anélkül, hogy módosítanánk az oszályt. | ||
Szükséges hozzá egy | 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. | 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. |
A lap 2012. december 17., 22:08-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é.
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.
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.
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.