Tartalom
Mi az antipattern? Egyszerű definícióval: olyan minta, ami megmondja, hogy egy problémától hogyan jutunk el egy rossz megoldásig. A pozitív része: az a jó, ha meg is magyarázza, hogy a rossz megoldás miért látszik vonzónak, miért rossz mégis, és milyen jó megoldásokat használjunk helyette.
Összehasonlításul: Mi a (design) pattern? Megfogalmaz egy gyakran előforduló problémát, és a hozzá tartozó megoldás lényegét. A megoldás olyan, hogy a probléma minden megoldásakor alkalmazhatjuk, de sosem gépiesen, hanem a konkrét helyzethez igazítva.
A lényeg talán az, hogy a sok-sok speciális eset megoldása helyett ismerjük fel az ismétlődő dolgokat (mintát), mert így már ismert megoldást találhatunk. Az antipatterneknél: ismerjük fel a rossz helyzeteket, hogy ne kövessünk el már ismert hibákat.
Mennyire féljünk attól, hogy újra elkövetünk ismert hibákat? Érdemes ezzel ennyit foglalkozni? – Bíztató statisztikai adatok:
Antipattern-ekről természetesen nem csak szoftver-fejlesztésnél beszélhetünk, hanem bármilyen más területen is. (A "pattern" fogalmat eredetileg az építészetben találták ki.) A szoftver-fejlesztésen kívül itt most csak a "menedzsment" antipattern-ekről lesz szó.
Az antipatternekhez hasonló megközelítés a bug pattern fogalma: ez nem annyira a rosszul alkalmazott megoldásokról szól, hanem inkább arról, hogy egyes programhibáknak (futás közbeni hibáknak) milyen gyakran előforduló okai lehetnek, mik azok a rossz kódolási módszerek, amik tipikusan hibát okoznak.
Másnéven: nagy sárkupac (big ball of mud).
Strukturálatlan, összetákolt rendszer. Vagy sosem volt megtervezve, vagy időközben a felismerhetetlenségig "erodálódott".
A látható jelek: semmitmondó vagy félrevezető függvény- és változónevek, globális változók, követhetetlen vezérlési szerkezetek, hosszú paraméterlisták, hosszú és körülményes eljárások, kódismétlés, elavult vagy hiányos dokumentáció, zűrös kapcsolatok az objektumok között, leszármaztatással nem bővíthető a rendszer, a polimorfizmus sem használható ki, objektum-orientált helyett "folyamat-orientált" metódusok és elnevezések.
Gyakran olyan kódból alakul ki, amit eredetileg ideiglenes, "eldobható kódnak" szántak, nem végleges megoldásnak – csak aztán mégis egyszerűbbnek tűnt tovább javítgatni, mint rendesen megcsinálni.
A tervezés sokszor háttérbe szorul a "hétköznapi" gondok mellett (időhiány), és luxusnak tűnik. A rövidtávú célokért (csak minél előbb működjön ez vagy az) könnyű feladni az azonnal nem megtérülő célokat.
Okozója lehet még a tapasztalatlanság (a tervezésnél nem tudjuk, hogy mi a jó megoldás, ezért nem születik jó architektúra), a programozók cserélődése, a gyenge szaktudás, illetve egyszerűen a probléma bonyolultsága (maga a probléma "csúnya", így csak csúnya modellt tudunk csinálni rá).
Másik ok az "erózió", vagyis az idők során megváltozó követelmények. Ezek előbb-utóbb olyan változtatásokat idéznek elő, amik az eredeti architektúrát alapjaiban felborítják.
Egy idő után annyira költséges lesz a karbantartása, hogy olcsóbb újraírni az egészet előlről, mint tovább foltozni.
Módszerek a javításra:
Stratégiák a megelőzésre:
Bővebben:
Másnéven: ravioli-kód (ravioli code).
Kicsit a spagetti kód oo-s megfelelője.
Az osztályok elszaporodása, állapot nélküli, rövid életű osztályok. ("Szellem" osztályok, amelyek példányai néha rövid időre megjelennek, csinálnak valamit, aztán eltűnnek.) Instabil tervezési modellek, az implementáció eltér a tervezéstől, rossz hatékonyság, nehéz bővíteni.
Módszer a javításra:
Egyetlen nagy osztály sok különböző művelettel és adattaggal. Hiányzik belőle az objektum-orientált tervezés, gyakran egy meglevő, nem oo-s rendszer migrálásából születik. Túl összetett ahhoz, hogy bővíteni vagy tesztelni lehessen, lassan töltődik be.
Módszer a javításra:
Bővebben:
MVC modell helyett egyetlen szervletbe bezsúfolva minden. (Mágikus gomb: egy gomb eseménykezelőjébe bezsúfolva minden.) A probléma lényege ugyanaz, mint a pacánál, csak itt kifejezetten olyan helyzetről van szó, amikor MVC-t lehet használni.
Bővebben:
Olyan kódrészletek felhalmozódása, amelyeket már nem használnak, sehonnan sem hívódnak.
String s = "Hello, "+name+"!";
Ezzel nincs baj, mert a fordító optimalizálni fogja: egy StringBuffer-ben állítja össze a stringet.
String s = "Hello"; s += name; s += "!";
Ezzel már baj van, mert minden hozzáadásnál külön String példányok fognak létrejönni, nem lesz StringBuffer!
Bővebben: