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

A VIK Wikiből
Ferrero (vitalap | szerkesztései)
Hryghr (vitalap | szerkesztései)
a Hryghr átnevezte a(z) Tervezési minták lapot a következő névre: Objektumorientált szoftvertervezés - Tervezési minták
(Nincs különbség)

A lap 2013. június 13., 22:09-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
  • 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)