Objektumorientált szoftvertervezés - Tervezési minták

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

9.1. Külső segédletek:

• Ezen a helyen volt linkelve a(z) jegyzetPatternek_.pdf nevű fájl ("Design_Patterns_jegyzet" link szöveggel) a régi wiki http://wiki-old.sch.bme.hu/bin/view/Infoszak/OotTervezesiMintak oldaláról. (Ha szükséged lenne a fájlra, akkor a pontos oldalmegnevezéssel együtt küldd el a wiki@NO-SPAM.sch.bme.hu címre a kérésedet)

néhány tervezési minta alaposabb kidolgozása

• Ezen a helyen volt linkelve a(z) Szoftvertechnikak_Design_Patters_16-17.pdf nevű fájl ("Szoftvertechnikak_Design_Patterns_16-17.pdf" link szöveggel) a régi wiki http://wiki-old.sch.bme.hu/bin/view/Infoszak/OotTervezesiMintak oldaláról. (Ha szükséged lenne a fájlra, akkor a pontos oldalmegnevezéssel együtt küldd el a wiki@NO-SPAM.sch.bme.hu címre a kérésedet)

Szoftvertechnikak_Design_Patterns_16-17.pdf

9.2. 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é.

Ezen a helyen volt linkelve a callback.png nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

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.

Ezen a helyen volt linkelve a factory.png nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

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.

Ezen a helyen volt linkelve a mobileagent.png nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

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.

9.3. 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.