Egységbezárás

"Szervusz, Amigo! A mai előadást a kapszulázásnak szeretném szentelni . Már van egy általános elképzelésed arról, hogy mi az."

Milyen előnyei vannak tehát a kapszulázásnak? Sok van, de kiemelek négyet, amelyek véleményem szerint a legfontosabbak:

1) Érvényes belső állapot.

A programoknak gyakran több osztálya is van, amelyek kölcsönhatásba lépnek ugyanazzal az objektummal. Ha az objektum belső adataival egyidejűleg lépnek kapcsolatba, megsérthetik az objektum adatintegritását, ami miatt az objektum nem működik megfelelően.

Tehát az objektumnak nyomon kell követnie a belső adataiban bekövetkezett változásokat, vagy ami még jobb – a változtatásokat neki kell végrehajtania.

Ha nem akarjuk, hogy egy osztályváltozót más osztályok módosítsanak, akkor privátnak nyilvánítjuk , ami azt jelenti, hogy csak az adott osztály metódusai férhetnek hozzá. Ha azt szeretnénk, hogy a változók csak olvashatóak legyenek más osztályok számára, akkor ezekhez a változókhoz adunk nyilvános gettert .

Például azt szeretnénk, hogy mindenki tudja, hány elem van a gyűjteményünkben, de senki sem módosíthatja azt az engedélyünk nélkül. Ebben az esetben deklarálunk egy private int count változót és egy public getCount() metódust .

A megfelelő beágyazás garantálja, hogy más osztályok ne férhessenek hozzá közvetlenül osztályunk belső adataihoz, következésképpen ne módosíthassák azokat anélkül, hogy mi ellenőrizhetnénk tevékenységeiket. Meg kell hívniuk a metódusokat abban az osztályban, amely a módosítandó változókat tartalmazza.

A legjobb azt feltételezni, hogy más programozók mindig a számukra legkényelmesebb módon fogják használni az osztályokat, nem pedig úgy, ahogyan az Ön (vagy az osztálya) számára a legbiztonságosabb lenne. Ez a hibák forrása, és egy módja annak, hogy megelőzzük őket.

2) Paraméterellenőrzés.

Néha ellenőriznie kell az osztály metódusaiba átadott paramétereket. Tegyük fel például, hogy van egy osztályunk, amely egy "személyt" képvisel, és megadhatja a születési dátumát. Ellenőriznünk kell, hogy minden átadott adat megfelel-e a program és az osztály logikájának. Pl. nincs 13. hónap, nincs február 30. stb.

"Miért jelezne valaki február 30-i születési dátumot?"

– Nos, először is lehet, hogy adatbeviteli hiba eredménye.

Másodszor, mielőtt egy program úgy működne, mint az óramű, sok hibája lehet. Például előfordulhat ilyesmi.

Egy programozó kódot ír, amely meghatározza, hogy kinek van holnapután születésnapja. Tegyük fel, hogy ma március 3. A program 2-t ad az aktuális dátumhoz, és mindenkit megtalál, aki március 5-én született. Eddig minden rendben.

De amikor eljön március 30, a program nem talál senkit, mivel nincs március 32. A programok sokkal kevésbé hibásak, ha a metódusok paraméterellenőrzést végeznek."

"Emlékszem, amikor az ArrayList-et tanulmányoztuk, megnéztem a kódját, és a get és set metódusokban ellenőrizték, hogy az index paraméter nagyobb-e vagy egyenlő-e nullával és kisebb-e, mint a tömb hossza. A kód egy kivétel, ha a tömbben nem volt az indexnek megfelelő elem.

"Igen, ez a klasszikus bemenet-ellenőrzés. "

3) Kevesebb hiba az osztályokon belüli kód megváltoztatásakor.

Tegyük fel, hogy egy nagyon hasznos órát írtunk egy hatalmas projekt részeként. Mindenkinek annyira tetszik, hogy más programozók több száz helyen kezdték használni a saját kódjukban.

Az óra annyira hasznosnak bizonyult, hogy úgy döntöttél, javítasz rajta. De ha megszabadulsz az osztály bármely metódusától, több tucat másik programozó kódja nem fog többé lefordítani. Gyorsan át kellene írniuk a kódjukat. És minél több újraírás történik, annál több lehetőség nyílik a hibákra. Ha rendszeresen megtöröd az építményt, gyűlölni fogsz.

De ha megváltoztatjuk a privátként megjelölt metódusokat, tudjuk, hogy ezeket a metódusokat sehol nem hívja meg senki más kódja. Átírhatjuk őket, módosíthatjuk a paraméterek számát és típusát, és a függő kód továbbra is működik. Vagy legalábbis még összeáll.

4) Meghatározzuk, hogy más objektumok hogyan hatnak egymásra az objektumunkkal.

Korlátozhatjuk, hogy milyen műveleteket tehetünk tárgyunkon. Például azt szeretnénk, ha egy osztálynak csak egy példánya jönne létre – még akkor is, ha a projektben egyszerre több helyen jön létre. Ezt pedig kapszulázással érhetjük el.

A beágyazás lehetővé teszi további korlátozások bevezetését, amelyek további előnyökkel járhatnak . Például a String osztály megváltoztathatatlan objektumként van megvalósítva. A String osztály példányai létrehozása és megsemmisítése között nem változtatható meg. A String osztály összes metódusa (remove, substring, ...) új karakterláncot ad vissza, és semmilyen módon nem változtatja meg a meghívott objektumot.

"Szent tehén. Szóval ez így van."

– A kapszulázás izgalmas.

"Egyetértek."