Anti-Patterns avagy Ellenpéldák

A gyakran előforduló, negatív következményekkel járó probléma megoldásokat gyűjtik össze az ellenpéldák. Hasonlóan a tervezési mintákhoz, ezek is jól dokumentáltak. Leír egy általános formát, megadja az oda vezető okokat és körülírja a tüneteket, ezek alapján felfedezhető az ellenpélda. Fontos, hogy a jól dokumentált ellenpélda ezeken túl, leírja a következményeket is és utat mutat az újragyártáshoz (refactoring), illetve konkretizálja is azt.

Tömören, olyan módszerek, amelyek valós tapasztalatokkal szolgálnak a visszatérő hibák, problémák felismerésében és részletes leírást, javaslatot adnak azokra.

Röviden pár ellenpélda:

Spagetti kód (Spaghetti code)

Kiváltó ok a lustaság és a tudatlanság. Bonyolult kezelhetőség jellemzi, egy-egy függvény sok, akár egymástól független dolgot is tartalmaz, nincs szeparáltság, nagyon kevés objektumot tartalmaz (az igényekhez képest), teljes a struktúrálatlanság. Az ilyen kódot egyszerűbb újra írni, mint a módosítással próbálkozni, mert a rendszert bonyolult bővíteni és karbantartani. Nincs lehetőség a modulok, objektumok felhasználására egy hasonló rendszerben.

A massza (The Blob)

Más néven: Az Isten Osztály, általában lustaság, sietség miatt jön létre. A teljesítményben és funkcionális elvárásokban alul teljesít, túl bonyolulttá válik a kód. Egyetlen osztály tartalmaz szinte mindent, eltérő műveleteket és tulajdonságokat.

A rendszer kevéssé módosítható anélkül, hogy a bezárt objektumok működése megváltozna. Viszont ezen objektumok megváltozása kihat a teljes szoftverre. 

Lávafolyam (Lava Flow)

Hívják még Halott Kód-nak (Dead Code) is, eredetileg kutatási célból írt kódot (próbakódot) tovább fejlesztették végtermékké, és ezek a korábbi fejlesztési irányok már bazalt-szerű eltávolíthatatlan kódtömegek lettek. Legtöbbször nem is használt kódok, eredetük kevéssé vagy egyáltalán nem ismert (a fejlesztő már nincs a cégnél), eredményül kód töredékeket kapunk melyek nem egyértelműen kapcsolódnak a rendszerhez.

Vágólap kódolás (Clipboard coding)

Rossz erőforrás kezelést eredményez, nehéz átadni a kódot másnak. Tipikus hiba: „Hé, azt hittem ezt a hibát már javítottad, miért csinálja már megint?”.

A vágólap programozás elég elterjedt, mivel egy meglévő kódot átvenni, módosítani egyszerűbb, mint újat létrehozni a semmiből. Ezzel önmagában nincs baj, viszont könnyen hibázhatunk, ha nem ismert kódot másolunk, hiszen ha vannak hibák, akkor azokat is átvesszük, valamint ha nem figyelünk a létrehozási és az új környezetre, könnyen új hibák is adódhatnak.

Kísértet (Poltergeist)

A kísértetek rövid életű, tipikusan állapot nélküli osztályok, melyek más metódusokat hívnak meg. Általában valamilyen menedzser vagy kontroller osztályoknak hívják őket (xy_manager), tipikusan azért készültek, hogy más osztályok metódusait hívják meg általában előre meghatározott sorrendben. Redundáns navigációs utakat eredményeznek, erőforrásokat pazarolnak és feleslegesen összezavarja az objektum modellt.

Funkcionális dekompozíció (Functional Decomposition)

Ismert még: Nem OO, vagyis nem Objektum Orientált ellenpéldaként is. Ez az ellenpélda, akkor mutatkozik, ha nem OO fejlesztők OO nyelven próbálnak alkalmazást implementálni, így például a szubrutinokhoz létrehoznak egy-egy osztályt, ezzel figyelmen kívül hagyva az osztály hierarchiát. A kód így nagyon hasonlít egy strukturális nyelvben (PASCAL) történő megvalósításhoz, azzal a különbséggel, hogy a strukturáltságot az osztály struktúra adja. Egy tipikus jele például, osztályok egyetlen függvénnyel.

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.