„Objektumorientált szoftvertervezés - Tervezési minták” változatai közötti eltérés
(autoedit v2: fájlhivatkozások egységesítése, az új közvetlenül az adott fájlra mutat) |
|||
| (4 közbenső módosítás, amit 2 másik szerkesztő végzett, nincs mutatva) | |||
| 3. sor: | 3. sor: | ||
==Külső segédletek:== | ==Külső segédletek:== | ||
| − | [[ | + | [[Media:jegyzetPatternek_.pdf]] - néhány tervezési minta alaposabb kidolgozása |
| − | [[ | + | [[Media:Szoftvertechnikak_Design_Patterns_16-17.pdf]] - Szoftvertechnikak_Design_Patterns_16-17.pdf |
==Mintkák röviden== | ==Mintkák röviden== | ||
| 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 | + | [[File: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 | + | [[File: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 | + | [[File: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. | ||
| 89. sor: | 90. sor: | ||
* JTree-nél Null Object pattern | * JTree-nél Null Object pattern | ||
* SortedSet -> Comparator pattern | * SortedSet -> Comparator pattern | ||
| − | * | + | * Chatserver, SAX eseményvezérlése -> Callback pattern |
* Bankfiók életciklus -> Factory pattern | * Bankfiók életciklus -> Factory pattern | ||
* RMI stub, szövegszerkesztő -> Proxy pattern | * RMI stub, szövegszerkesztő -> Proxy pattern | ||
* Beágyazott mobil Java ME eseménykezelője (registry miatt)-> Whiteboard pattern | * Beágyazott mobil Java ME eseménykezelője (registry miatt)-> Whiteboard pattern | ||
| + | * java.concurrent.CopyOnWriteArrayList -> Composite | ||
| + | * java.util.Comparator -> Strategy | ||
| + | * java.rmi.server.RemoteStub -> Proxy | ||
| + | * javax.swing.GroupLayout.ParalellGroup -> Strategy | ||
-- [[SallaiTamas|sashee]] - 2009.05.19. <br /> | -- [[SallaiTamas|sashee]] - 2009.05.19. <br /> | ||
| 98. sor: | 103. sor: | ||
-- [[FelberPeter|Eff]] - 2010.06.12. | -- [[FelberPeter|Eff]] - 2010.06.12. | ||
| + | --[[Szerkesztő:Ferrero|Szabó Csaba]] ([[Szerkesztővita:Ferrero|vita]]) 2012. december 17., 22:44 (CET) | ||
[[Category:Infoszak]] | [[Category:Infoszak]] | ||
A lap jelenlegi, 2017. július 12., 14:22-kori változata
Tartalomjegyzék
Külső segédletek:
Media:jegyzetPatternek_.pdf - néhány tervezési minta alaposabb kidolgozása
Media: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
- java.concurrent.CopyOnWriteArrayList -> Composite
- java.util.Comparator -> Strategy
- java.rmi.server.RemoteStub -> Proxy
- javax.swing.GroupLayout.ParalellGroup -> Strategy
-- sashee - 2009.05.19.
-- Velias - 2009.05.26.
-- Eff - 2010.06.12.
--Szabó Csaba (vita) 2012. december 17., 22:44 (CET)
