Ezzel a cikkel egy szoftvertervezéssel és tervezési mintákkal foglalkozó sorozat indul el. A cikkek a tervezés fontosságára és az objektumorientáltság alapelveire világítanak rá.
A szoftverfejlesztés esetében nem kirívó eset, hogy az elsőre jó ötletnek tűnő megoldás hibásnak bizonyul. A kód részleges átírása, illetve rossz esetben akár a teljes újraírása gyakorlatilag része a folyamatnak. Ez még akkor is előfordulhat, ha előzőleg megterveztük az alkalmazást, és nem ad hoc módon történik a fejlesztés.
Tervezéskor nem biztos, hogy képesek vagyunk feltérképezni az összes előreláthatatlan problémát. Különösen a következő esetekben igaz ez:
- Új, vagy kevésbé ismert technológiát alkalmazunk
Például új, vagy továbbfejlesztett, bővített függvénykönyvtárakat, COM-objektumokat, komponenseket kell használnunk; olyan rendszerekkel, infrastruktúrával kerülünk kapcsolatba, amely nincs teljes körűen letesztelve, dokumentálva;
- Az alkalmazott technológiáról menet közben derül ki, hogy nem tesz eleget az alkalmazással szemben támasztott követelményeknek (biztonság, teljesítmény, memóriahasználat, hardverigény stb.)
Más lapra tartozik az az eset, amikor világos és részletes terv ellenére is hibásan történik a fejlesztés. Ez az eset a kód rendszeres ellenőrzésével (code review) szűrhető ki.
A kód módosítása tehát gyakorlatilag nem kerülhető el. Azonban nem mindegy, hogy ez mekkora erőfeszítést jelent.
Pályafutásom során már többször részt vettem olyan kód javításában, amelyben kusza volt, kibogozhatatlan, és szinte minden függött mindentől. A legkisebb módosítás is végighullámzott a project nagy részén, ezáltal a karbantartás, hibajavítás egy rémálom volt.
Az objektum-orientáltág alapelveinek betartásával sokat lehet segíteni a helyzeten. Egy átgondolt osztály-struktúra, az objektumok közötti függőségek átgondolása, az egységbezárás, adatrejtés, többalakúság kiaknázásával máris minőségibb szoftvert eredményez.
Megjegyzés
A lyukkártátyól a struktúrált programozáson keresztül hosszú út vezetett az objektumorientált szoftverfejlesztésig; bár utóbbi sem újkeletű, még mindig látni olyan projectet, amely csak nevében objektum-orientált.
A klasszikusnak számító strukturált programozás nehézkessé teszi a méretesebb, összetettebb rendszerek megvalósítását, karbantartását és továbbfejlesztését.
Természetesen mindazt, amit C++-ban, Java-ban, C#-ban vagy Objective-C-ben, objektumorientáltan fejlesztünk, megvalósítható strukturáltan C-ben, Pascal-ban vagy éppenséggel Assemblyben is. Azonban létezik egy lényeges különbség: a fejlesztés és karbantartás hatékonysága, azaz az ehhez szükséges munkaidő!
A következő lépcsőfokot a minőségi szoftvertervezésben és írásban az úgynevezett tervezési minták bevetése jelenti. Az építészetből átvett fogalom lényege, hogy a fejelsztők jól bevált és kipróbált megoldásokat alkalmazzanak, ahelyett, hogy folyamatosan újra feltalálnák a spanyolviaszt. A szakma négy nagyja - Gamma, Helm, Johnson, és Vlissides - méltán vált híressé azzal, hogy összefoglalta a legáltalánosabban alkalmazott mintákat. A “Gang of four” 23 mintát taglal “Tervezési minták” című, immár klasszikusnak számító könyvében. A minták által az objektumok létrehozását, függőségeit, illetve viselkedését foglalják keretbe. A megfelelő minta alkalmazásával átláthatóbb, rövidebb, optimálisabb és könnyebben karbantartható alkalmazás valósítható meg.
Megjegyzés
A szoftverfejlesztési tervminták népszerűek, és egyre szélesebben alkalmazzák őket. Előfordul, hogy egyesek ösztönösen tervmintákkal dolgoznak - úgy, hogy nem is tudnak róla.
A következő cikkben néhány olyan jelet mutatok be, amelyek a rossz minőségű kódra utalnak.
Nyisztor Károly, 2009
http://www.nyisztorkaroly.org
| < Előző | Következő > |
|---|
