Objektumtobzódás
A számítógép-programozásban az objektumtobzódás az objektumorientált programozás egyik gyakori hibája. Jellemzője, hogy az objektumok nem zárják magukba az információikat, hanem korlátlan hozzáférést engedélyeznek belsejükhöz. Ez megnehezíti a karbantartást, és fenntarthatatlanul bonyolulttá teheti a programot. Az elnevezés a Perl programozói közösségéből ered.
Következményei szerkesztés
A következmények az információelrejtés hiányából adódnak:
- A korlátlan hozzáférés megnehezíti, hogy következtessünk egy objektum viselkedésére. Ez azért van, mivel a rendszer összes többi összetevője hozzáfér, ami megnöveli az átvizsgálandó kód mennyiségét, a bővítés pedig az adatokkal való visszaélést kockáztatja.
- A viselkedés megjósolhatatlansága miatt a szerződés alapú programozás nem valósítható meg hatékonyan.
- Ha a kód nagy részének előnye származik abból, hogy szabadon hozzáfér az adatokhoz, akkor az eredmény az interakciók nehezen karbantartható halmaza, ami spagettikódként is ismert.
- Az eredeti tervet elrejti az objektumok túlzottan bő interfésze.
- A túl bő interfész megnehezíti, hogy kicseréljék egy osztály megvalósítását anélkül, hogy az egész viselkedése rejtélyes módon meg ne változzon. Ez különösen akkor nehéz, ha mások írnak hozzá klienseket.
Formái szerkesztés
Az egységbe zárás többféleképpen is gyengíthető:
- Publikus adattagok, vagy getter-setter metódusok minden adattaghoz.
- Nem nyilvános hozzáférés engedélyezése, mint csomagszintű láthatóság (és minden egy csomagban), vagy barát függvények, osztályok. Lásd: Java hozzáférési módosítók, C# hozzáférhetőségi szintek,[1] C++ friend.
Az objektumok belső adatai referenciákkal is kiszöktethetők, amikor paraméterként továbbadjuk őket. Ezzel szemben, ha objektumok referenciákkal hivatkoznak egymásra, önmagában nem töri meg az egységbe zárást.
Okai szerkesztés
A tagokat deklarálhatják nyilvánosnak sietségből, a terv meg nem értése miatt vagy azért, hogy egyszerűsítsék a kódot azzal, hogy nem kell hozzáférést biztosító függvényeket írni. Ez ideiglenesen javítja az olvashatóságot is.
Vannak rosszul tervezett nyelvek, ahol nincs lehetőség arra, hogy egy publikusnak deklarált tagot kívülről módosíthatatlanná tegyenek.
A terv meg nem értése azzal jár, hogy a programozó nem érti, nem tudja, hogy az objektum mely más objektumokkal áll kapcsolatban, így biztos, ami biztos, mindenkinek hozzáférést engedélyez. A problémák felmerülésekor át kell tekinteni a kódot; ennek elmaradása a többi antiminta megjelenésének is kedvez.
Megoldások szerkesztés
Általában a terv vagy egyes osztályok követelik meg az egységek megbontását, így újratervezés szükséges. Ha nem ez a helyzet, akkor elég átstrukturálni a kódot. Ha egyszer az interfészeket visszavonhatatlanul deklarálták, akkor túl késő őket kijavítani.
Jegyzetek szerkesztés
- ↑ MSDN: Accessibility Levels, Visual Studio .NET 2003 Archiválva 2008. április 17-i dátummal a Wayback Machine-ben).
Források szerkesztés
Fordítás szerkesztés
Ez a szócikk részben vagy egészben az Object orgy című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.