Programtervezési minták

Az előadások a következő témára: "Programtervezési minták"— Előadás másolata:

1 Programtervezési minták
Az OO rendszereket együttműködő objektumok alkotják Kulcskérdés az újrahasznosíthatóság A tervezési minták bizonyos tervezési feladatokat oldanak meg, miközben rugalmas, elegáns, és újrahasznosítható kódot eredményeznek Analógia: színdarab írók – tragikus hős (Macbeth, Hamlet)

2 Alapfogalmak Objektum (object) Metódus (method, operation)
Kérés (request) Egységbezárás (encapsulation) Interfész (interface) Öröklődés <-> kompozíció (inheritance, composition)

3 Programtervezési minták
Használatának előnyei: Újrahasznosítja a már bevált, sikeres architektúrákat Elkerülhetők a mellékvágányok Akár a dokumentációt is segítheti: egyértelműen definiált osztályok, objektumok, együttműködés, stb. Segít elsőre jó megoldást választani

4 Programtervezési minták
Cél Létrehozás Struktúra Viselkedés Osztály Factory Method Adapter Interpreter Template Method Objektum Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Proxy Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor

5 Programtervezési minták

6 Tervezési minták Abstract Factory Builder Factory Method Prototype
Singleton Adapter Bridge Composite Decorator Façade Flyweight Proxy Product objektum családok Hogyan készíthetünk kompozit objektumokat Alosztályokba tartozó objektum instanciák. Objektumok készítése meglévő példányokból Egy osztály egyetlen példánya Interfész egy objektumhoz Egy objektum implementálása Egy objektum struktúrája és megalkotása Feladatok alosztályok készítése nélkül.. Interfész egy alrendszerhez Az objektumok tárolási költségei Hogyan érhetünk el egy objektumot

7 Tervezési minták Chain of Responsibility
Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Objektum, ami egy kérésre válaszol Mikor és hogyan hajtunk végre egy kérést. Egy nyelv nyelvtana és interpretációja. Egy aggregátum elemeinek (egymás utáni) elérése Hogyan és mely objektumok működnek együtt. Mikor és milyen privát adatok tárolódnak el az objektumról Egymástól függő objektumok frissítésének megvalósítása Objektum állapotainak kezelése Egy algoritmus Egy algoritmus lépései Objektumokon végrehajtandó műveletek – az osztályaik megváltoztatása nélkül.

8 Tervezési minták használatának esetei
Objektum létrehozása az osztály explicit megadásával: Az objektum létrehozásakor az osztály megadása kötöttségekkel jár, mai a jövőbeli változtatásokat megakadályozhatja. Ezt elkerülendő hozzuk létre az objektumokat indirekt módon. Design patterns: Abstract Factory, Factory Method, Prototype. Adott műveletektől való függőség: amikor egy megadott műveletet adunk meg, akkor rögzítjük a kérés kielégítésének a módját. Lehetőség van használhatunk mind fordítási, mind futási időben létrehozott módon kielégíteni a kéréseket. Design patterns: Chain of Responsibility (223), Command (233). Hardver és szoftverplatformtól való függés. Külső, operációs rendszer interfészek és az alkalmasok program interfészei (API) különbözőek leheznek különböző hardver és szoftver platformokon. Az ilyen függőséggel rendelkező szoftvert nehéz hordozhatóvá tenni – adott esetben a natív platformján is nehéz karbantartani. Tervezéskor próbáljuk meg a platformfüggőséget korlátozni. Design patterns: Abstract Factory, Bridge. Objektum reprezentációtól vagy implementációtól való függőség. Azokat a klienseket, amelyek tudják, hogyan reprezentálunk, tárolunk, azonosítunk, implementálunk objektumokat gyakran meg kell változtatni, amikor ezek az objektumok megváltoznak. Ha elrejtjük a kliensek elől az információt akkor elkerülhetjük a változások végigvezetését. Design patterns: Abstract Factory, Bridge, Memento, Proxy. Algoritmikus függőség: Az algoritmusok növekednek, optimalizálódnak, cserélődnek a fejlesztés során. Az algoritmusoktól függő objektumoknak meg kell változniuk, amikor az algoritmus megváltozik. Ezért különítsük el azokat az algoritmusokat, amelyek valószínüleg megváltoznak. Design patterns: Builder, Iterator, Strategy, Template Method, Visitor.

9 Tervezési minták használatának esetei
Szoros kapcsolat. Azokat az osztályokat, amelyek egymással szorosan kapcsolódnak nehéz újrahasznosítani, hiszen egymástól függenek. A szoros kapcsolat monolit rendszerhez vezet, ahol nem lehet megváltoztatni, törölni osztályokat anélkül, hogy megértsünk és módosítsonk több másik osztályt is. A rendszer egy nagy, tömör masszává válik, amit nehéz megtanulni, portolni, karbantartani. A laza kapcsolódás megnöveli az újrafelhasználás valószínűségét, A tervezési minták olyan módszereket használnak erre, mint az absztrakt kapcsolódás vagy a többrétegű alkalmazások. Design patterns: Abstract Factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer. A működés kiterjesztése alosztályokkal. Alosztályok létrehozása nem mindig fájdalommentes. Minden új osztály implementációs költséggel jár (inicializálás, befejezés, stb.) Az aloszály létrehozása az ősosztály mély megismerését igényli. Például az egyik művelet override-olása a másik művelet override-olását vonhatja maga után. Az alosztályok létrehozása az osztályok számának drasztikus megnövekedésével járhat, mivel a legkisebb kiterjesztés is egy új alosztály bevezetésével járhat. Az objektum kompozíció általában, a delegáció pedig különsen rugalmas alternatívája az öröklődésnek. Az alkalmazásnak új funkcionalitást adhatunk úgy, hogy meglévő objektumokból építkezünk és nem meglévő osztályokat terjesztünk ki. Másrészt, az objektum kompozíció széleskörű használata csökkenti az érthetőséget. A tervezési minták többsége csupán egyszeres öröklődést használ, ls az elérendő funkcionalitást a meglévő példányok kompozíciójával éri el. Design patterns: Bridge, Chain of Responsibility, Composite, Decorator, Observer, Strategy. Az osztályok alig módosíthatók. Néha olyan osztályokat szükséges módosítani, amiket nem lehet kényelmesen módosítani. Például szükség lenne a forráskódra, ami nem áll rendelkezésre, vagy egy csomó alosztályt is meg kellene változtatni. A tervezési minták bizonyos lehetőségeket adnak ilyen osztályok megváltoztatására. Design patterns: Adapter, Decorator, Visitor.

10 Factory Cél Alkalmazási terület Egyéb megnevezés:
Definiálunk egy interfészt, amelyen keresztül egy objekumut létrehozunk. A példányosítást az alosztályok végzik – eldöntve melyik osztályba tartozó product-ot készítenek. A Factory Method az alosztályokra hagyja a példányosítást. Egyéb megnevezés: Virtuális konstruktor Alkalmazási terület Előre nem látható osztályba tartozó objektumok készítésére Egy osztály az alosztályaira bízza, milyen objektumokat készítsen Az osztály átruházza a felelősséget a megfelelő alosztályok egyikére. A delegálásra vonatkozó kódot lokalizálja.

11 Factory

12 Factory Példa: NamerFactory

13 Abstract factory Cél Egyéb megnevezés Alkalmazási terület
Egymástól függő objektum családok létrehozásához biztosít interfészt anélkül, hogy a konkrét osztály megadását kérné. Egyéb megnevezés kit Alkalmazási terület A rendszer nem függ attól, hogyan készítjük el a product-jait. Használatára konfigurálhatjuk Egy családba tartozó productok használhatók, a család egységes használata kikényszeríthető Osztálykönyvtárak hozhatók létre úgy, hogy csak az interfészeiket kell feltárnunk, az implementációikat nem

14 Abstract factory

15 Singleton Cél Alkalmazási terület Struktúra
Biztosítani, hogy egy osztály kizárólag egy példányban létezik, és biztosítani a hozzáférést hozzá. Alkalmazási terület Ahol egy osztálynak pontosan egy példánya lehet, és a kliensek egy megadott módon érhetik azt el. Struktúra

16 Builder Cél Alkalmazási terület
Elválasztani egy bonyolult objektum összeállítását annak reprezentációjától. Így ugyanaz az összeállítási folyamat más-más reprezentációt eredményezhet Alkalmazási terület Egy komplex objektum létrehozásának algoritmusa független attól, milyen objektumokból áll össze a komplex objektum, és hogyan rakjuk össze az építőelemeket Az objektum összeállításnak folyamata különböző reprezentációkat enged meg.

17 Builder

18 Builder

19 Prototype Cél Alkalmazási terület
Meghatározni a prototípus után megalkotandó objektumok körét azért. hogy az újonnan létrehozandó objektumokat ezek klónozásával alkossuk meg. Alkalmazási terület Amikor a rendszernek függetlennek kell lennie attól, hogyn készítjük és reprezentáljuka at objektumait és Amikor a példányosítandó osztályokat futásidőben adjuk meg; vagy El kell kerülni a factory-k – amelyek párhuzamos productokat készítenek - osztályhierarchiáját; vagy Amikor az osytályok példányai csupán néhány állapotot vehetnek fel. Kényelmesebb lehet néhány prototipust adni és ezeket klónozni, mint a példányokat egyesével létrehozni az ostályokból, és ezeket a megfelelő állapotba állítani

20 Prototype

21 Prototype JAVA nyelven a clone() metódus a java.lang.Object osztályból öröklődik. A beépített clone() un. shallow copy módszert használ Shallow copy: Az eredeti objektum és annak primitív adattagjai lemásolódnak. Az alsóbb szintű objektumoknak csak referenciái másolódnak, azaz az eredetit megváltoztatva a másolat is változik Deep copy: Az eredeti objektumnak mind a primitív adattagjai, mind az alobjektumai másolódnak.