Amit tudnod kell fejlesztőként, III. rész: Tervezési minták

Mai témánk a fejlesztői eszközökkel és a komplexitáselmélettel ellentétben kevésbé egyértelmű. Sokan kritikus szemmel tekintenek a design patternekre, és talán igazuk is van (később erről is szót ejtünk), mégis gyakran találkozunk velük, így azt gondolom, valamilyen szintű ismeretük elengedhetetlen és egyben hasznos is.

Mik a tervezési minták? A Wikipedia szerint általános, újrafelhasználható megoldások gyakran előforduló objektum-orientált problémákra. A tervezési minta azt mondja meg, hogyan strukturáljuk osztályainkat egy adott követelmény kielégítése érdekében — egyfajta tervrajzot ad az alkalmazásunk egy részének felépítését illetően. Fontos megjegyezni, hogy nem ad tervrajzot az egész alkalmazás felépítésére, és nem is konkrét algoritmusokat ír le.

Nézzük meg először, mi ennek a megközelítésnek az előnye. Elsősorban nyilván az, hogy (ahogy az algoritmusok esetében is említettem) nem találjuk fel újra a spanyolviaszt akkor, amikor az teljesen felesleges; nem is beszélve arról, hogy a saját módszerünk valószínűleg gyengébb a jól átgondolt, gyakran kipróbált patterneknél. Másrészt — és ez talán ugyanolyan fontos —, mivel a tervezési minták kötött terminológiával rendelkeznek, könnyedén szót értünk más fejlesztőkkel a problémát illetően, hiszen a közös tudás birtokában azonnal tudja minden fél, hogy pontosan miről van szó.

Természetesen nincs módunk a téma részletes kifejtésére (még kevesebb a különböző minták ismertetésére) — arra ott van például a ma már klasszikusnak számító Design Patterns című könyv — de kezdésnek átfuthatjuk, egyáltalán milyen típusú minták léteznek, és milyen jellegű problémákra kínálnak megoldást. Eszerint négy nagy csoportot különböztetünk meg.

A létrehozási minták (creational patterns) objektumok speciális módon történő példányosítására adnak alternatívákat (tipikus példák: Abstract Factory, Singleton, Factory Method). Itt általában az objektumokat nem közvetlenül a konstruktoron keresztül példányosítjuk, növelve ezzel valamilyen szempontból a flexibilitást.

A strukturális minták osztálya némileg sokszínűbb; általános értelemben azt mondhatjuk, hogy az entitások közötti kapcsolatok meghatározásával segítik a tervezést. Hogy ezt a zavaros meghatározást jobban megértsük, nézzünk meg egy-két tipikus példát: a Facade minta például több osztály interfészét egyesíti egy komponensben, az Adapter minta pedig egy osztály interfészét alakítja át úgy, hogy az megfeleljen egy adott "fogyasztó" számára — az eredeti osztály megváltoztatása nélkül.

A viselkedési minták gyakori kommunikációs formákat írnak le objektumokat között, és kínálnak erre jól működő konstrukciókat. A csoport legismertebb tagjai a Strategy, amely azonos problémát megoldó algoritmusok implementációját fedi el azzal, hogy cserélhetővé teszi őket, vagy például a Memento, amely egy objektum belső állapotát tárolja (főleg a későbbi visszaállítás érdekében) anélkül, hogy megsértené az egységbe zárás alapelvét. Utolsó nagy kategóriánk a konkurens minták csoportja, amely nevét nem meghazudtolva a párhuzamos programozás gyakran előforduló problémáira ad tervrajzokat.

Amellett, hogy érdemes a fenti kategóriákból minél többet megismerni, Jeff Atwood szerint hajlamosak vagyunk ezek hatására túltervezni az alkalmazásainkat, és azokba a szituációkba is beleerőltetni bizonyos mintákat, ahová nem valók. Látható tehát, hogy a tervezési minták helyes használata igényel némi tapasztalatot. Mielőtt azonnal a design patternekhez fordulnánk, próbáljunk inkább egyszerű megoldást találni a problémára az adott kontextusban — ha azon kapjuk magunkat, hogy rengeteg felesleges kódot, osztályt írunk csak azért, hogy megfeleljünk egy adott mintának, valószínűleg érdemes újragondolnunk, mit is csinálunk éppen.

Peter Norvig azt is megmutatja, hogy ezek a minták sok esetben csupán bizonyos programozási nyelvek hiányosságait fedik fel. Ebben az 1998-as cikkben például rávilágít, hogy a korábban említett Design Patterns könyv 23 mintájából 16 kiiktatható, ill. leegyszerűsíthető a Lisp, vagy a Dylan nyelvekben.

Jól látszik tehát, hogy — ahogy az a legtöbb dologra igaz — a tervezési minták semmiképp sem jelentik a Szent Grált, de a megfelelő helyen és időben bevetve őket hasznosnak bizonyulhatnak.