Tervezési minták - 1. rész

Mielőtt elolvasnád a cikket, pár apróság:

• A cikk feltételez egy bizonyos alapismeretet a programozás terén.
• Jó, ha tudod mi az objektum orientált programozás vagy legalább kacsingatsz felé.
• Felismerted, hogy a szép és áttekinthető kód nem presztízs, sokkal inkább létkérdés.
• Ha már olvastad vagy láttad valahol a singleton vagy factory szavakat, de még nem tudod mit jelentenek, akkor jó helyen jársz.

A tervezési minták általánosságban előforduló problémákra kínálnak (újra és újrafelhasználható) megoldást.

Miért használjunk mintákat?

Mert már bevált megoldásokat kínálnak, bizonyítottan működnek. A minták elég kifejezőek, általuk könnyebb akár egy nagyobb kódot is átlátni vagy a működését felismerni, mivel a mintáról azt is tudjuk mire is kínált megoldást.

Mire figyeljünk oda?

Fontos megértenünk, hogy csak a megoldandó probléma pontos ismeretében tudjuk kiválasztani a megfelelő tervezési mintát! Valamint tudni kell, hogy nem minden esetben kell/lehet egy mintát használni.

A minták nem pontos vagy tökéletes kivitelezést nyújtanak, és nem is adnak mindenre megoldást!

A tervezési minták nem platform függetlenek, vagyis egy olyan nyelvben, mint például a Javascript ahol nincsenek osztályok, nem vagy csak nehezen valósítható meg egy-egy tervezési minta, bármennyire is tudjuk az osztályokat funkciókkal szimulálni.

Nézzünk egy példát egy viszonylag egyszerű esetre

Ha webes, tisztán Javascriptes oldalon maradva, azt a feladatot kapjuk, hogy írjunk kódot AJAX technikával, ami lekérdez egy bizonyos adatot egy távoli szerverről, akkor bizony mindjárt egy olyan probléma előtt találjuk magunkat, hogy nem mindegy milyen böngésző alatt is kell erre a problémára megoldást írni. A példa kedvéért feltételezzük, hogy Internet Explorer 6 és egy modernebb böngészőre is működnie kell a kódunknak. Így felvetődik az a probléma is, hogy környezet függő lett a kódunk, máshogy kell megírni IE6-ra és máshogy egy modernebb böngészőre.

Az ilyen tipikusan környezettől függő (böngésző kompatibilis) problémákra kínál jó megoldást a FACADE minta. (A FACADE mintával később bővebben is foglalkozunk.)

Ha ezzel a mintával kivitelezzük a feladatot, akkor egy picit komplexebb kódot írunk viszont eredményül olyan újrahasznosítható metódust/függvényt kapunk, ami böngésző független és elvégzi a feladatát.

Ha nem használjuk a mintát, akkor - elvileg - annyi metódust kell írni a feladatra, ahány – az AJAX kérdéskörben - különböző módon működő böngésző van.

A minták 3 főbb kategóriája

• Létrehozási minták (Creational Design Patterns)
• Szerkezeti minták (Structural Design Patterns)
• Viselkedési minták (Behavioral Design Patterns)

A létrehozási minták

A létrehozási minták az objektumok létrehozási (gyártási) folyamatának kezeléséről szólnak, hogy a szituációnak mindig a legmegfelelőbb módon hozzuk létre a kívánt objektumot. Az alap feltevése ezen mintáknak, hogy az objektumok gyártásának módja egyszerű és hasznos legyen, ne legyen túl bonyolítva, ez által a kódunk érthetőbb és átláthatóbb maradjon.

Valamint két fontos jellemzőjük van, az egyik, hogy a létrehozáshoz szükséges tudást, folyamatot magukba zárják, a másik, hogy ez a folyamat a külvilág (kliens) felé rejtve marad. Ez azért fontos, mert másnak így nincs beleszólása a létrehozási folyamatba, nem alakul ki függőség, sokkal rugalmasabb marad a kódunk a változások felé.

A létrehozási minták közé tartoznak a következők: Constructor, Factory, Abstract-Factory, Prototype, Singleton és Builder

Szerkezeti minták

Amikor több osztállyal és objektummal dolgozunk, lényeges kérdés, hogyan tudunk ezekből nagyobb és összetettebb szerkezeteket alkotni, ilyenkor ezek egymáshoz való viszonya, kapcsolata nagyon meghatározó, kellően rugalmasnak kell maradnia a szerkezetnek, különben a későbbi fejlesztést nagymértékben hátráltatni fogja a szervezetlenség.

Elég csak belegondolni, mi történik egy webshoppal, ha a fejlesztési előkészületeknél nem gondolunk arra, hogy később nem csak forintban, hanem más pénznemben is szeretnék árakat kezelni. Ha az ilyen apróságokra és a menet közbeni folyamatos bővítésekre nem készítjük fel a leendő rendszerünket, akkor - később - a fejlesztésközben gyorsan erodálódni fog a kódunk.

A szerkezeti minták közé a következők tartoznak: Decorator, Facade, Flyweight, Adapter, Bridge, Composite és Proxy

Viselkedési minták

Ezek a minták általában az osztályok és az objektumok közötti kommunikációval és felelősségi körök kijelölésével foglalkoznak. Bonyolult vezérlési folyamatoknál találkozhatunk a viselkedési mintákkal.

A viselkedési minták közé a következő minták tartoznak: Iterator, Mediator, Observer, Visitor, Command, Interpretet, Memento, State, Strategy, Template Method és a Chain of Responsibility

A következő részben – még mielőtt a belekezdünk a tervezési mintákba – az Anti-patternekről (ellen-példák) lesz szó.

Ha tetszett a cikk, véleményed van, kiegészítenéd vagy hibát találtál, írj a cikk alatt egy kommentet, vagy írd meg emailben.