A tervezési minta dióhéjban: kipróbált és bevált, az objektum-orientált nyelvekben alkalmazott megoldás. Eredetileg az építészetben alkalmaztak mintákat, azonban a programfejlesztésben ugyancsak hasznosnak bizonyultak. Habár első ránézésre nem rokonszakmákról van szó, ha jobban belegondolunk, nem is állnak olyan messzire egymástól: végső soron szoftverfejlesztőként kisebb-nagyobb építőelemekből hozunk létre működő alkalmazásokat.A témában megjelent szakkönyvek (legalábbis amelyeket volt szerencsém olvasni) néha feleslegesen túlbonyolítják a fogalmakat - mintha készakarva túlmisztifikálnák ezt a témakört!
A mintákat nehezen követhető, elavult példákkal szemléltetik. Amit leginkább hiányolok, az a minták előnyeinek ecsetelése az "essünk-neki-aztán-lesz-ami-lesz" (avagy brute-force) megoldásokkal szemben.
Tehát nem véletlen, hogy egyesek még mindig strukturáltan programoznak OO-nyelvekben, vagy éppenséggel átesnek a ló másik oldalára, és akkor is eröltetik, amikor valójában felesleges.
Jobb esetben felépítjük a megfelelő osztályhierarchiát, amely alapján rendezett kódot igyekszünk írni, és végül mégis kényelmetlenül összetett eredményt kapunk.
Érezzük ugyan, hogy valami nem jó, de nem tudjuk, hogy mi a gond? Végülis létrehoztuk a dedikált osztályokat, elláttuk megfelelő függvényekkel, felépítettük a kapcsolatokat - elsőre minden szép. Azonban amint bővítésre vagy hibajavításra kerül sor, a legkisebb változtatás is áthullámzik szinte minden forrásfájlon.
Ha ez a helyzet, a probléma valószínűleg a következő lehet:
- egyáltalán nem, vagy rosszul terveztünk (no design / bad design - nagyjából rokonértelmű szavaknak tekinthetők ;-))
- nem alkalmaztunk tervezési mintákat (az előbbi ponttal szorosan összefügg)
Az okok között szerepelhet:
- a megfelelő szakértelem hiánya
- a napi rutinként elvégzett droid-munka miatt történő elbutulás, elkényelmesedés
- a szervezetlenségből, rossz vezetői döntésekből adódó lehetetlen határidők, és az ennek köszönhető kapkodás, stressz
Szerencsére több alternatíva is létezik a problémák orvoslására.
Amit a cég tehet az ügy érdekében:
- (rendszeres) ellenőrzés intézményesítése, tapasztaltabb szakember bevetésével (code-inspection, code-review)
- design és project megbeszélések beiktatása a munkarendbe
- oktatások szervezése
- a munkaerő időnkénti rotálása különböző projectekben, a rutinmunkába történő elfáradást, elbutulást elkerülendő
- a projectvezetők, menedzserek rendszeres értékelése, szakmailag és nem utolsó sorban emberileg egyaránt(*)
(*)Egy kis kitérő: egyesekre ráerőltetik például a projectvezetői szerepkört, bár egyáltalán nem tud kommunikálni. Találkoztam már olyannal is, akinek hangzatos "architekt" státusza volt, azonban nem tudta, mi a különbség az aggregáció és a kompozíció között.
Előfordul, hogy valaki addig rágja a felettese fülét, amíg megszerzi a kívánt pozíciót - anélkül, hogy bejárta volna a szükséges lépcsofokokat. Mindez törvényszerűen feszültséghez vezet, és jól felismerhető az úgynevezett "lefele tapos, felfele nyal" kórtünet. Sajnos mindössze hatalomvágytól hajtva kerülhetnek vezető pozícióba olyan emberek, akik szakmailag vagy emberileg egyszerűen nem alkalmasak a feladatra (nem politizálunk, kizárólag a mi szakmánkról beszélek! :-D).
Amit Te tehetsz:
- önképzés - a jobb cégek általában támogatják ezt, élj a lehetőségekkel! (pl. szakkönyvek beszerzése, jelentkezés oktatásokra, illetve igény jelzése a felettesek felé)!
- megfelelő munkahely keresése ;-)
A "Shaderprogramozás, Grafika és játékfejlesztés DirectX-szel" című, játékfejlesztésről szóló könyvben felvillan egy-két tervezési minta, a tervezett folytatásban pedig hangsúlyos szerepet kapnak.
Tervezési minták nélkül az osztályok, objektumok között bonyolult, kusza kapcsolatokat kellene fenntartani, amelyek nehezen átlátható kódot, nagyobb memóriafogyasztást, rosszabb teljesítményt eredményeznek - hogy csak néhány negatívumot említsek.
Egy olyan kód, amelyben egyáltalán nem alkalmazunk tervezési mintákat, karbantartás és bővíthetőség szempontjából igazi rémálom.
Szerencsére a fejlesztők többsége ösztönösen alkalmaz mintákat, hiszen a "józan paraszti ész" is ezt diktálja. Idővel, a jó példákból okulva kialakul egyfajta reflexszerű hozzáállás az alkalmazás tervezéséhez, fejlesztéséhez, és jó esetben a rossz minták és megszokások kirostálódnak. Azonban ehhez mindenképp szükséges a fejlődni- és tanulni akarás.
Üdvözlettel,
Nyisztor Károly
http://www.nyisztorkaroly.org
| < Előző | Következő > |
|---|
