• email
  • facebook
  • linkedin
  • google+
  • pinteres

Mintázatok a forrásban: design patternek

Alexander: Pattern Language

Amikor az ember laikussal beszélget, és próbálja elmagyarázni, mit is jelent a szoftverfejlesztés valójában, milyen fajta szellemi kihívásokat rejt, a leginkább kézenfekvő valamiféle analógiát találni: egy más, ám mégis hasonló mesterséget. Steve McConnell a Code Complete könyv első szakaszainak egyikében ennél is tovább megy: azt írja, a szoftverfejlesztő számára is, hogy igazán értse a saját szakmáját, s újra és újra inspirálni tudja saját gondolkodását, elengedhetetlen, hogy megtalálja a leginkább találó metaforát, vagy éppen több metafora kombinációját. Azt hiszem mindkét esetben, ha barátnak vagy ha magának próbálja a fejlesztő megvilágítani, miben is áll a munkája, a leggyakoribb párhuzam: az építészé. Egy szoftver fejlesztése nem más, mint a tervező mérnöké, aki egy épületet tervez meg a külső megjelenéstől a statikai számításokon át egészen az apróbb részletekig.

Nem meglepő az sem, hogy az objektum-orientált programozás egyik legfontosabb, rendszer szintű fogalma szintén az építészetből ered. Ez a fogalom: a design pattern. (Viszonylag elterjedt fordítás a tervezési minta kifejezés, viszont gyakran használt az eredeti, angol forma is. Én igyekszem majd a kettőt egészséges arányban keverni.) A design pattern kifejezést Christopher Alexander vezette be A Pattern Language: Towns, Buildings, Construction című könyvében, amelyben megpróbált egy az építészetben érvényes pattern nyelvet kialakítani. Hogy mennyire lett ebben sikeres, nem igazán tudom, de egy építész ismerősök körében végzett kisebb körbekérdezés után azt hiszem, hogy ma több fejlesztő mint építész ismeri Alexander nevét, és pláne több használja a design pattern kifejezést.

Fowler: P of EAA

A design pattern (tervezési minta) Alexander könyvében az építészet egyes kategorizálható, egyetemes feladataira, problémáira kínált megoldásokban próbálja a hasonlóság mintázatait megragadni. Talán ennek az egyetemes igénynek, a néhol szinte ezotérikussá váló belátásoknak köszönhető, hogy az építészetben kevesebb sikerre vitte a fogalom. A szoftverfejlesztésben és tervezésben sokkal szűkebb a fogalom értelmezési tartománya: elsősorban az objektum orientált szoftver tervezés tipikus problémáira kínálható nagyobb érvényességi körű (ha nem is 100%-ban általánosítható) megoldásokat nevezhetjük programtervezési mintáknak. A tágabb értelemben vett cél is szerényebb, mint Alexanderé volt: nem egy általános érvényű nyelvet próbál alkotni -- bár persze nem mindenki tud ellenállni a nagyság csábításának --, sokkal inkább bővíteni a fogalomkészletet, amely segítségével meg tudjuk ragadni, és ami legfontosabb, meg tudjuk oldani a rendszerek tervezése során felmerülő problémákat.

Martin Fowler az egyik legismertebb tervezési mintákkal foglalkozó könyv, a Patterns of Enterprise Application Architecture szerzője számos más írásában és honlapján is tárgyalja a tervezési minták szerepét, s egy helyütt maga is úgy fogalmaz: a pattern nyelv megalkotásának igényénél sokkal fontosabb, hogy használható megoldásokat kapjunk. Mint mondja sem a saját könyve, sem a GoF nem tekinthető a pattern nyelv megalkotására történt kísérletnek.

GoF

S hogy mi is a GoF? A Gang of Four, azaz a négyek bandája: Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides által írt Design Patterns: Elements of Reusable Object-Oriented Software című könyv, amely az objektum orientált programozás világába a patterneket bevezette. (A könyv magyarul is megjelent, sajnos szívszorítóan brutális áron, és eléggé erőltetett kényszerfordításokkal: Egyke, Elvont gyár, Gyártófüggvény...) Nekik köszönhetjük, hogy számos tervezési minta, mint például a Singleton, az Observer vagy a Strategy pattern annyira a mindennapjaink részévé vált, hogy nem is tudunk róluk: a mindannyiunk által használt JDK-ban is számos máshol leírt tervezési mintát találunk éles alkalmazásban -- melyekről szeretnék majd egyszer külön írni, csakúgy mint a többi izgalmas GoF patternről.

Mint említettem, a tervezési minták talán legfontosabb közvetlen haszna, hogy fogalomkészletet adnak a számunkra, hogy egyből megláthassunk és megragadhassunk hasonló problémákat, s azokhoz a megoldás sémáját is kínálja. Nézzünk egyetlen példát. Aki kicsit is ismeri a SWinget, tudja, minden Java kliens komponensek fa szerkezetben megjeleníthető hierarchiájából áll. Minden komponens (javax.swing.JComponent melynek még magasabb szintű AWT-s ősosztálya a java.awt.Component) felelős a maga, illetve a maga által tartalmazott komponensek -- ha vannak ilyenek -- megrajzolásáért. Kívülről a fa bármely eleme ugyanolyan viselkedést mutat. Ez az egyszerű alap logika nem más, mint a GoF Composite patternje:

Compose objects into tree structures to represent part-whole hierarchies. Composite lets client treat individual objects and compositions of object uniformly.
J2ee patternek

Mióta az ilyen általános, alap szintű (sőt ennél sokkal mindennapibb) problémák terén kiderült, mennyire hasznos, ha tervezési mintákkal bővítjük az eszközkészletünk, a tipikusan vállalati szoftverek fejlesztése során felmerülő problémák tartományára érvényes patternek leírására is többen vállalkoztak. Az egyik legsikeresebb kísérlet az említett Fowler munka. Szűkebben a Java EE (akkor még J2EE) világ problémáira alkalmazható tervezési mintákat tartalmaz a Deepak Alur, Dan Malks és John Crupi által összeállított Core J2EE Patterns című kötet. Ebben a Java EE rétegzési struktúrájához illeszkedő megoldásokat találunk, amelyek egy része a legtöbb Java EE fejlesztő számára ismerős ma már: mint például a DAO-k (Data Access Object) vagy DTO-k (Data Transfer Object) használata, vagy a Front és Application Controller patternek, amelyek a kliens felől érkező kérések kiszolgálására egyetlen érkeztetési-továbbítási pontot definiálnak (gondoljunk például webes alkalmazásnál egy dispatcher szervletre, amely a requestek feldolgozása után a business réteg megfelelő komponensei felé továbbítja a feldolgozott kérést, majd a visszakapott eredmény kliens felé történő továbbításáról is gondoskodik -- a gyorsabb megértéshez UML grafikonok találhatók itt).

Ezeknek a tervezési mintáknak számottevő része elavulhat az idők során, ahogy az újabb eszközök -- jelentős részben éppen a petternek tapasztalatai nyomán -- kiküszöbölik azokat a problémákat, amelyek kezelésére a patternek szolgáltak. Remek példa, hogy a 3.0-ás szabvány előtti EJB patternek jelentős része azzal a problémával foglalkozott, hogy az entity beanek a korábbi szabványok szerint megosztott erőforrások voltak, azaz a szerveren lévő objektumot lehetett elérni remote interfacen keresztül, miközben praktikusan a fejlesztők nagy része könnyű súlyú domain objektumként szerette vola őket használni. Legemlékezetesebb talán a Session Façade, amely az entity beanek menedzselését kizárólag session beaneken keresztül engedte meg, így küszöbölbe ki az entity beaneken keresztül történő szerverhívásokat. A 3.0-ás EJB szabvány óta az entityk szimpla POJO-k, nem megosztottak, így a Session Façade helyett (ahhoz bizonyos tekintetben nagyon hasonló, ám már a rendszerbe belegondolt) egyszerűbb megoldás kínálkozik az entityk kezelésére.

Érdemes még megjegyezni, hiszen a tervezési minták sikerét mutatja, hogy több írás, könyv is született, amely a programtervezés tipikus hibáit, tévútjait, az úgynevezett anti-patterneket gyűjti össze. Ilyenek például a Singletonitis, a Singleton pattern túlhasználása, vagy a God object antipattern, amely óva int attól, hogy egyetlen objektumba túl sok funkciót és adatot erőltessünk, hiszen ez az objektum orientált gondolkodás kudarca, amennyiben a tervezés során nem sikerült a funkcionalitás kisebb elemi egységekre bontani.

Tervezési mintákkal tehát sokfelé találkozhatunk, még ha sokszor nem is tudunk róla, hogy használjuk őket. Akkor pedig már sokkal hasznosabb ha ismerjük és értjük is ezt a hasznos gondolkodási eszközt. Segítségükkel hamarabb meglátunk hasonló problémákat, hatékonyabban oldhatjuk meg őket, és fejlesztőtársainkkal is jobban megérthetjük egymást, ha rátalálunk a patternek közös szókincsére.

Az itt megtalálható leírásokban a fontosabb, szimpatikusabb, vagy éppen csak aktuálisan érdekes tervezési mintákról szeretnék majd rövidebb ismertetőt elérhetővé tenni. A lista remélhetőleg folyamatosan bővül majd az idők során. Az összefoglalás remek alkalom lesz nekem is, hogy megértsem az adott patternt, és remélhetőleg más is haszonnal olvassa majd a bejegyzéseket.