Programtervezési minta

A Wikipédiából, a szabad enciklopédiából
(Programtervezési minták szócikkből átirányítva)

Az informatikában a programtervezési mintának (angolul Software Design Patterns) nevezik a gyakran előforduló programozási feladatokra adható általános, újrafelhasználható megoldásokat. Egy programtervezési minta rendszerint egymással együttműködő objektumok és osztályok leírása.[1]

Meg vagyok győződve róla, hogy a programtervezési minták a legjobb dolog, ami a programtervezéssel történt az objektumorientáltság feltalálása óta.
– - Design Patterns Explained[2]

A programtervezési minták fogalma[szerkesztés | forrásszöveg szerkesztése]

A programtervezési minták fogalma Christopher Alexander építész ötlete nyomán született meg. Ő volt az, aki olyan, az építészetben újra és újra felbukkanó mintákat keresett, amelyek a jól megépített házakat jellemzik. Könyvében, a „The Timeless Way of Buliding”-ben olyan mintákat próbált leírni, amelyek segítségével akár egy kezdő építész is gyorsan jó épületeket tervezhet. A minták a magukban hordozott különböző építészek sok éves tapasztalata miatt szebb, jobb vagy használhatóbb házakat eredményeztek, mintha a tervezőnek csupán saját erejére támaszkodva kellett volna megterveznie azokat.

Ez a könyv ihlette meg a 90-es évek elején a négyek bandájaként (angolul "Gang of Four" vagy GoF)-ként emlegetett Erich Gamma, Richard Helm, Ralph Johnson és John Vlissides programozó négyest, akik ekkor írták meg a Programtervezési minták [3] című könyvüket, amely ma is alapjául szolgál az objektumorientált programozási minták kutatásának.

Ez a könyv összesen 23 mintát mutat be,és a következő kategóriákba sorolja őket:

A szerzők kiemelik, hogy egyáltalán nem a valóságtól elrugaszkodott és elvont mintákat „találtak ki”, hanem csak összegyűjtötték a sokszor előforduló problémákat és a rájuk adott válaszokat, kielemezték őket, és a látottak alapján megpróbáltak általános megoldásokat nyújtani. A könyvben minden minta mellé leírták azt, hogy milyen felmerülő problémára adhat választ, alkalmazásának előnyeit és hátrányait, a megvalósítás lehetséges buktatóit, ismert felhasználásokat és példakódot, így teljes képet adva azok lehetséges használatának körülményeiről és eredményéről. Ez a könyv ma is referenciaként szolgál minden objektumorientált mintákkal kapcsolatos munkához.

Munkájuk alapján sok tervezési mintákkal foglalkozó közösség alakult, ezek közül talán a legismertebbek a Portland Patterns Repository [4] és a Hillside Group [5]. Mindkét oldal a tervezési minták népszerűsítését, a régi minták fejlesztését és új minták bemutatását tűzte ki céljául, a GoF könyvének szellemében. Az első kiadás óta eltelt több, mint tíz évben új könyvek sora is megjelent a témában, ezek közül a legismertebbek a Head First kiadó Design Patterns-e [6] és a Design Patterns Explained [2].

A programtervezési minták definíciója, helye[szerkesztés | forrásszöveg szerkesztése]

A programtervezési minták a GoF definíciója szerint: „egymással együttműködő objektumok és osztályok leírásai, amelyek testre szabott formában valamilyen általános tervezési problémát oldanak meg egy bizonyos összefüggésben”. A szoftvertervezésben egy-egy problémára végtelen sok különböző megoldás adható, azonban ezek között kevés optimális van. Tapasztalt szoftvertervezők, akik már sok hasonló problémával találkoztak, könnyen előhúzhatnak egy olyan megoldást, amely már kipróbált és bizonyított. Kezdő fejlesztőknek viszont jól jön, ha mindazt a tudást és tapasztalatot, amit csak évek munkájával érhetnek el, precízen dokumentálva kézbe vehetik, tanulhatnak belőle és az általa bevezetett kifejezésekkel könnyebben beszélhetik meg egymás között az ötleteiket. A programtervezési minták ilyen összegyűjtött tapasztalatok, amelyek mindegyike egy-egy gyakran előforduló problémára ad általánosított választ. Azonban mindezek mellett még számos előnyük van:

  • lerövidítik a tapasztalatszerzési időt. A programtervezési mintákat nem „feltalálták”, hanem a gyakran előforduló problémákra adott optimális válaszokat gyűjtötték össze, ezáltal olyan megoldásokat adtak, amelyekre előbb-utóbb a legtöbb fejlesztő magától is rájönne – csak esetleg jóval később. Természetesen nem kizárt, hogy léteznek jobb, hatékonyabb megoldások, és ritka amikor egy-egy mintát pontosan úgy lehet alkalmazni egy problémára, ahogy az a könyvekben le van írva, de mindenképpen érdemes megismerni őket, ha másért nem is, hogy elsajátíthassunk valamennyit a szerzők látásmódjából.
  • lerövidítik a tervezési időt. Az összes minta jól dokumentált, könnyen újrafelhasználható, így ha egyszer alkalmazzuk őket, jó eséllyel egy hasonló problémánál újra eszünkbe fognak jutni az összes előnyükkel és hátrányukkal együtt. Így azonnal hatékony, rugalmas megoldást adhatunk és megkímélhetjük magunkat sok tervezéstől és esetleges újratervezéstől. Ráadásul a minták után található „következmények” rész elősegíti, hogy teljesebb képet kapjunk az alkalmazás hatásairól is.
  • közös szótárat ad a fejlesztők kezébe. Ez megkönnyíti az egymás közti kommunikációt és a program dokumentálását is, hiszen könnyebb úgy beszélni egy probléma megoldásáról, ha van egy közös alap, ahonnan indulunk vagy amihez lehet hasonlítani az új terveket.
  • magasabb szintű programozást tesz lehetővé. Mivel ezek a minták elterjedtségük miatt már kiállták nagyon sok programozó próbáját, feltehetőleg az optimális megoldást tartalmazzák a problémára.

A programtervezési minták nem az egyetlen, a programozáshoz kapcsolható minták. Általában háromféle csoportosítást szoktak alkalmazni [7] :

  • Menedzsmenti (Managerial) minták : folyamatok és emberek kezelésének szintje
  • Építészeti (Architectural) : rétegek, erőforrások szintje
  • Tervezési (Design) : kódolási gyakorlatok, osztályok, objektumok szintje

Ezen kívül szokták használni a programozási minták (programming pattern) kifejezést azokra a programtervezési mintáknál kisebb mintákra, amelyek egy objektum belsejének részleteivel vagy egy nyelv elemeinek használatával foglalkoznak.


Tervezési minták osztályozása[szerkesztés | forrásszöveg szerkesztése]

Létrehozási minták
Név Leírás Design Patterns Code Complete (könyv) [8] Egyéb
Absztrakt gyár Létrehoz egy interfészt egymástól függő vagy valamilyen módon összekapcsolódó objektumok családjainak anélkül, hogy megadnánk a konkrét osztály típusát. Igen Igen n. a.
Építő Egy objektum felépítési folyamattal több, különböző szerkezetű objektumok létrehozására. A létrehozás folyamata független az objektum ábrázolásától. Igen Nem n. a.
Gyártó metódus Meghatároz egy interfészt egy objektum létrehozására, de a leszármazottakra van bízva az objektum típusának meghatározása. Segítségével elkerülhető, hogy

alkalmazás specifikus osztályokat rakjunk a kódba. (Kapcsolódó: Kontroll megfordítása)[9]).

Igen Igen n. a.
Lusta inicializáció Objektum létrehozás, költséges számítás, stb. késletetése addig, amíg nem válik szükségessé. Igen Nem PoEAA[10]
Többke Hasonlóan az egyke tervezési mintához, egy példány készítését teszi lehetővé, viszont nem alkalmazásonként hanem kulcsonként. A multiton osztály tartalmaz egy mapot a példányokról (key-value párok). Nem Nem n. a.
Objektum készlet Objektumok újrafelhasználása. Objektumok példányosítása és törlése költséges művelet lehet, ezért előre legyártott objektumokat használ az alkalmazás, és miután egy szükségtelenné vált, visszahelyezi azt az objektum készletbe. Tipikus példája a szálkészlet, amely processzek által használatos szálakat tárol. Nem Nem n. a.
Prototípus Meghatároz egy előzetes mintát az objektumok létrehozásához, és később ez kerül másolásra. Gyakran használjuk, ha az objektum pontos típusa csak futásidőben derül ki. Igen Nem n. a.
Egyke Biztosítja, hogy az osztályból csak egy példány készül, és biztosít egy publikus hozzáférést ehhez a példányhoz. Igen Igen n. a.
Szerkezeti minták
Név Leírás Design Patterns Code Complete (könyv) [8] Egyéb
Illesztő minta Egy felület átalakítása, illesztése egy másikra. Összeférhetetlen osztályok együttműködését teszi lehetővé. Igen Igen n. a.
Híd Lehetővé teszi az absztrakció (interfész) és az implementáció szétválasztását, így a kettő külön változtatható egymástól függetlenül. Igen Igen n. a.
Összetétel Az objektumok faszerkezetbe való ábrázolásának megvalósítása. Egységesíti a kezelését az objektumnak és objektumok összetételének. Igen Igen n. a.
Díszítő Lehetővé teszi az absztrakció változtatása nélkül további funkciók, felelősségi körök dinamikus hozzáadását. Igen Igen n. a.
Homlokzat Egy egységes magasabb szintű interfészt hoz létre egy alrendszer számos interfészének. Leegyszerűsíti a bonyolult rendszert, általa könnyebben használhatók az alrendszer funkciói. Igen Igen n. a.
Pehelysúlyú minta Sok egyforma objektum erőforrásaival hatékonyan gazdálkodik oly módon, hogy egy külön objektumban tárolja az újrahasznoítható (ismétlődő) funkciókat, tulajdonságokat. Igen Nem n. a.
Front Controller Web alkalmazásokhoz kapcsolódó tervezési minta. A beérkező kérések feldolgozásához és kiszolgálásához vezérléséhez használt módszer. Nem Igen n. a.
Modul Csoportosít számos összekapcsolódó, összefüggő objektumot egy entitásba. Nem Nem n. a.
Helyettes Egy másik objektum elfedésére, helyettesítésére alkalmazott tervezési minta. Igen Nem n. a.
Iker[11] Lehetőséget ad a többszörös öröklődés megvalósítására olyan programozási nyelvekben, ahol ez nem támogatott. Nem Nem n. a.
Viselkedési minták
Név Leírás Design Patterns Code Complete (könyv) [8] Egyéb
Blackboard Egy általánosított observer, amely engedélyez több írót és olvasót. Rendszerszintű az információ áramlása. Nem Nem n. a.
Felelősséglánc Az üzenet vagy kérés küldőjének függetlenítése a fogadótól. Megvalósítása felelősségláncok kialakításával történik. Lényegében egy láncolt lista, amin a kérelem végig halad mindaddig, amíg egy objektum le nem tudja kezelni. Igen Nem n. a.
Parancs Kérelmek objektumba ágyazása. Ezáltal a klienseknek különböző parancsokat adhatunk át, amit naplózhatunk, sorba rendezhetünk és a visszavonást kezelhetjük le. Azaz az egyes kérelmek teljesen kivizsgálhatóak és hatálytalaníthatók lesznek. Igen Nem n. a.
Értelmező Meghatározza az adott nyelv értelmezőjének a forráskód értelmezésének nyelvtanát, szabályait. Igen Nem n. a.
Iterator Lehetővé teszi egy aggregált objektum elemeinek szekvenciális elérését anélkül, hogy láthatóvá tenné a mögöttes reprezentációját. Igen Igen n. a.
Közvetítő Több egymással kapcsolatot tartó objektum kommunikációjának egységbe (objektumba) zárása. Definiál egy interfészt, amin keresztül objektumokkal kommunikálhat. Igen Nem n. a.
Memento Az egységbezárás megsértése nélkül a külvilág számára elérhetővé tenni az objektum belső állapotát. Így az objektum állapota később visszaállítható. Igen Nem n. a.
Null objektum Null referenciák elkerülése érdekében null helyett egy alapértelmezett objektummal (null object) térnek vissza a metódusok. Nem Nem n. a.
Megfigyelő Meghatároz ez egy-a-többhöz függőséget objektumok között. Egy adott objektum módosulásáról automatikus értesítő információt küld a tőle függő objektumoknak, amik ezek alapján frissülnek. Igen Igen n. a.
Szolga Osztályok csoportjának biztosít funkciókat, melyeket elvégez az osztályok helyett. Az adott funkciók csak a szolga osztályban vannak megvalósítva. Nem Nem n. a.
Specifikáció Egyesíti az alkalmazások üzleti logikáját Boole-algebra-szerűen. Nem Nem n. a.
Állapot Az objektum viselkedése megváltoztatható a belső állapottól függően. Igen Nem n. a.
Stratégia Egységbe zárt, azonos interfésszel rendelkező algoritmusok dinamikus cserélgetése. Lehetővé teszi, hogy az algoritmus az őt használó kliensektől függetlenül változzon. Igen Igen n. a.
Sablon függvény Az algoritmus vázának megvalósítása oly módon, hogy bizonyos közbenső végrehajtási lépések specializálhatók legyenek az alosztályokban. Igen Igen n. a.
Látogató Lehetőséget ad új funkciók hozzáadására anélkül, hogy megváltoztatnánk az osztályok szerkezetét. Igen Nem n. a.


Konkurencia minták
Név Leírás POSA2 (könyv)[12] Egyéb
Aktív objektum Függetleníti a metódushívást a futtatásától. Célja a konkurencia megvalósítása aszinkron metódushívással és egy ütemezővel a kérések feldolgozásához. Igen n. a.
Balking (akadályozó) Csak akkor futhat le egy függvény az objektumban, hogyha az objektum egy bizonyos állapotában van. Nem n. a.
Kötési tulajdonságok (Binding properties) Több megfigyelő (observer) egyesítése annak érdekében, hogy több objektum tulajdonságait szinkronizálni, koordinálni lehessen. Nem n. a.
Duplán ellenőrzött lock-olás Megosztott erőforrások többszálú hozzáférését teszi lehetővé. Először teszteli, hogy rá lehet-e lock-olni az adott lock-ra, és csak utána teszi meg. Igen n. a.
Esemény-alapú aszinkron minta Több szálon futó alkalmazások szálkezelési problémáit célozza meg.[13] Nem n. a.
Őrzött felfüggesztés Olyan műveleteket kezel, amely futásához a lock megszerzése mellett bizonyos feltételeknek is teljesülniük kell. Nem n. a.
Join Olyan magas szintű programozási modell, ami által konkurens, parallel és elosztott programokat írhatunk, üzenetek átadásával. Nem n. a.
Lock (zár) Egy szál zárat (lock-ot) tehet a forrásra, megakadályozva ezzel azt, hogy más szálak hozzáférjenek vagy módosítsák azt. Nem PoEAA[10]
Üzenetküldő (MDP) Lehetővé teszi az alkalmazások, komponensek közötti üzenetváltást. Nem n. a.
Monitor objektum Egy olyan objektum, amely segítségével zárolni lehet objektumokat, amíg inkonzisztens állapotban vannak. Monitorokat használva fellép a holtpont (deadlock) lehetősége. Igen n. a.
Reactor A reactor objektum aszinkron interfészt biztosít olyan forrásoknak, amelyeknek szinkronban kell futniuk. Igen n. a.
Író/olvasó lock Lehetővé teszi egy objektum egyidejű olvasását, viszont az íráshoz egyszerre csak egy szál férhet hozzá. Nem n. a.
Ütemező Ütemezi, irányítja, hogy mikor melyik szál futtathat le egy adott egy szálon futtatandó kódot. Nem n. a.
Szálkészlet Egy adott mennyiségű, sorban (queue) elhelyezett, előre legyártott szál, amelyekkel elkerülhető a szálak költséges legyártása és eltakarítása. Object pool egy speciális változata. Nem n. a.
Szál-specifikus tároló Statikus (globális) memória egy adott szálnak. Igen n. a.

Jegyzetek[szerkesztés | forrásszöveg szerkesztése]

  1. Szabolcsi Judit: Szoftvertechnológia - Programtervezési minták (Design Pattern)
  2. ^ a b Desing Patterns Explained, i. m. 
  3. Desing Patterns (könyv), i. m. 
  4. The Portland Patterns Repository. (Hozzáférés: 2009. november 23.)
  5. The Hillside Group. (Hozzáférés: 2009. november 23.)
  6. Head First Design Patterns, i. m. 
  7. AntiPatterns, i. m. 
  8. ^ a b c McConnell, Steve. Design in Construction, Code Complete, 2nd, Microsoft Press (2004. június 1.). ISBN 978-0-7356-1967-8 „Table 5.1 Popular Design Patterns” 
  9. Design Patterns: Dependency injection. (Hozzáférés: 2011. április 13.) „The use of a factory class is one common way to implement DI.”
  10. ^ a b Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley (2002). ISBN 978-0-321-12742-6 
  11. Twin – A Design Pattern for Modeling Multiple Inheritance
  12. Schmidt, Douglas C.. Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons (2000). ISBN 0-471-60695-2 
  13. Christian Nagel, Bill Evjen, Jay Glynn, Karli Watson, and Morgan Skinner. Event-based Asynchronous Pattern, Professional C# 2008. Wiley, 570–571. o (2008). ISBN 0-470-19137-6 

Források[szerkesztés | forrásszöveg szerkesztése]

  • Alan Shalloway, James R. Trott. Desing Patterns Explained. Addison-Wesley, 337. o. ISBN 0-201-71594-5 (2002) 
  • Alexander, Christopher. A Pattern Language. Oxford University Press (1977). ISBN 0195019199 
  • Gamma, Helm, Johnson & Vlissides. Design Patterns (könyv). Addison-Wesley (1994). ISBN 0-201-63361-2 
  • Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates. Head First Design Patterns. O’Reilly Media, 638. o. ISBN 0-596-00712-4 (2004) 
  • William J. Brown, Raphael C. Malveau, Hays W. "Skip" McCormick , Thomas J. Mowbray. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. Wiley, 336. o. ISBN 0-471-19713-0 (1998)