Objektumorientált szoftvertervezés - Tervezési minták
Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.
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
Tartalomjegyzék
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 wikiHiba a bélyegkép létrehozásakor: Nem lehet a bélyegképet a célhelyre mentenisch.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 wikiHiba a bélyegkép létrehozásakor: Nem lehet a bélyegképet a célhelyre mentenisch.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é.
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.
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.
