„Objektumorientált szoftvertervezés - Tervezési minták” változatai közötti eltérés

A VIK Wikiből
Ferrero (vitalap | szerkesztései)
Nincs szerkesztési összefoglaló
Nagy Marcell (vitalap | szerkesztései)
autoedit v2: fájlhivatkozások egységesítése, az új közvetlenül az adott fájlra mutat
 
(3 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:==


[[Fájl:jegyzetPatternek_.pdf]] - néhány tervezési minta alaposabb kidolgozása
[[Media: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
[[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é.


[[Fájl: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.


[[Fájl: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.


[[Fájl:mobileagent.png]]
[[File:mobileagent.png]]




90. 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
* 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 />
99. 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., 15:22-kori változata

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)