Információ elrejtése
 |
Ezzel a szócikkel vagy szakasszal kapcsolatban felmerült kifogás(ok):
|
A számítástechnikában az információ elrejtése a tervezési döntések elkülönítésének elve egy számítógépes programban, amelyek a legnagyobb valószínűséggel változnak, így megóvják a program más részeit a jelentős módosításoktól, ha a tervezési döntés megváltozik. A védelem magában foglalja egy stabil interfész biztosítását, amely megvédi a program többi részét a megvalósítástól (amelynek részletei valószínűleg megváltoznak). Másképpen fogalmazva, az információ elrejtése az a képesség, hogy megakadályozza, hogy egy osztály vagy szoftverösszetevő bizonyos aspektusai elérhetőek legyenek a kliensek számára, akár programnyelvi funkciók (például privát változók), akár explicit exportálási szabályzat esetén.
Áttekintés[szerkesztés]
A beágyazás kifejezést gyakran az információ elrejtésével felcserélve használják. Nem mindenki ért egyet abban, hogy különbséget kell tenni a kettő között. Az információrejtés ebben az esetben az elv, míg a beágyazás a technika. A szoftvermodul elrejti az információkat azáltal, hogy az információt egy modulba vagy más interfészt bemutató konstrukció magába zárja.[1]
Az információrejtést gyakran használják az adatok fizikai tárolási elrendezésének elrejtésére. Így ha módosítják, a változtatás a teljes program egy kis részhalmazára korlátozódik. Például, ha egy háromdimenziós pontot (x, y, z) ábrázolunk egy programban három lebegőpontos skalárváltozóval, majd később, egy három méretű tömbváltozóra módosul, egy információrejtő modulra, szem előtt tartva a program többi részének védelmét egy ilyen változástól.
Az objektum-orientált programozásban az információrejtés (a típusok egymásba ágyazásával) csökkenti a szoftverfejlesztés kockázatát azáltal, hogy a kód függőségét egy bizonytalan megvalósítástól (tervezési döntés) egy jól definiált felületre helyezi át. Az interfész kliensei tisztán az interfészen keresztül hajtják végre a műveleteket, így ha a megvalósítás megváltozik, a klienseknek nem kell változniuk.
Egységbezárás[szerkesztés]
Grady Booch, az objektum-orientált tervezésről szóló könyvében, a beágyazást úgy határozta meg, mint "az absztrakció szerkezetét és viselkedését alkotó elemek részekre bontásának folyamata; a beágyazás az absztrakció szerződéses interfészének és megvalósításának elválasztására szolgál".[2]
A cél a változás lehetőségének elérése: a komponens belső mechanizmusai a többi komponensre gyakorolt hatás nélkül fejleszthetők, vagy a komponens egy másik, ugyanazt a nyilvános felületet támogató komponensre cserélhető. A beágyazás az összetevő integritását is védi, mivel megakadályozza, hogy a felhasználók az összetevő belső adatait érvénytelen vagy inkonzisztens állapotba állítsák. A beágyazás másik előnye, hogy csökkenti a rendszer összetettségét, és ezáltal növeli a robusztusságot, mivel korlátozza a szoftverkomponensek közötti kölcsönös függőséget.[2]
Ebben az értelemben az egységbezárás gondolata általánosabb, mint az objektum-orientált programozásban való alkalmazása. Például egy relációs adatbázis beágyazott abban az értelemben, hogy egyetlen nyilvános felülete egy lekérdezési nyelv (például SQL), amely elrejti az adatbázis-kezelő rendszer összes belső gépezetét és adatstruktúráját. Mint ilyen, a beágyazás a jó szoftverarchitektúra alapelve, a részletesség minden szintjén.
Az interfész mögé beágyazott szoftver lehetővé teszi olyan objektumok felépítését, amelyek utánozzák az objektumok viselkedését és interakcióit a valós világban. Például egy egyszerű digitális ébresztőóra egy valós tárgy, amelyet egy laikus (nem szakértő) használhat és megérthet. A mellékelt interfészen (gombok és képernyő) keresztül megérthetik, mit csinál az ébresztőóra, és hogyan kell használni, anélkül, hogy az óra minden részét megértenék. Hasonlóképpen, ha az órát egy másik modellre cserélnék, a laikus továbbra is ugyanúgy használhatná, feltéve, hogy az interfész ugyanúgy működik.
Egy objektum-orientált programozási nyelv konkrétabb beállításában a fogalom vagy információrejtő mechanizmust, kötegelő mechanizmust vagy a kettő kombinációját jelenti. (Részletekért lásd: Beágyazás (objektumorientált programozás).)
Történelem[szerkesztés]
Az információrejtés fogalmát először David Parnas írta le 1972-ben.[3][4] Azelőtt Richard Gauthier és Stephen Pont tárgyalta a modularitást 1970-ben megjelent Designing Systems Programs című könyvében, bár magát a moduláris programozást sok kereskedelmi telephelyen már sok évvel korábban használták – különösen I/O alrendszerekben és szoftverkönyvtáraknál – anélkül, hogy megszerezték volna a 'information hiding' (információrejtés) címkét – de hasonló okokból, csakúgy mint a nyilvánvalóbb kód-újrahasználat miatt.
Példa[szerkesztés]
Az információk elrejtése hatékony kritériumként szolgál bármely berendezés, szoftver vagy hardver funkcionalitási modulokra való felosztására. Például az autó egy összetett berendezés. Annak érdekében, hogy az autók tervezése, gyártása és karbantartása ésszerű legyen, az összetett berendezést modulokra osztják, amelyek speciális interfészekkel rejtik el a tervezési döntéseket. Egy autó ilyen módon történő tervezésével az autógyártó különféle lehetőségeket is kínálhat, miközben gazdaságos gyártású járművel rendelkezik.
Például egy autógyártó rendelkezhet az autó luxusváltozatával, valamint szabványos változatával. A luxusváltozat erősebb motorral érkezik, mint a standard változat. A két különböző autómotort, egyet a luxusváltozathoz és egyet a standard változathoz tervező mérnökök mindkét motorhoz ugyanazt a felületet biztosítják. Mindkét motor az autó motorterébe illeszkedik, ami a két változat között azonos. Mindkét motorhoz ugyanaz a sebességváltó, ugyanazok a motortartók és ugyanazok a kezelőszervek tartoznak. A motorok között az a különbség, hogy az erősebb luxusváltozat nagyobb lökettérfogatú üzemanyag-befecskendező rendszerrel, amely úgy van programozva, hogy a nagyobb lökettérfogatú motorhoz szükséges üzemanyag-levegő keveréket biztosítsa.
Az erősebb motor mellett a luxusváltozat további lehetőségeket is kínálhat, például jobb rádiót CD-lejátszóval, kényelmesebb üléseket, jobb felfüggesztést szélesebb gumikkal és különböző fényezési színeket. Mindezekkel a változtatásokkal az autó nagy része megegyezik a standard és a luxus változat között. A CD-lejátszós rádió a szabványos rádiót helyettesítő modul, amely szintén modul a luxusmodellben. A kényelmesebb ülések ugyanabba az üléstartóba vannak beépítve, mint a normál típusú ülések. Nem számít, hogy az ülések bőrből vagy műanyagból készülnek, vagy deréktámaszt kínálnak-e vagy sem.
A mérnökök úgy tervezik meg az autót, hogy a feladatokat munkadarabokra osztják, amelyeket csapatoknak osztanak ki. Ezután minden csapat egy adott szabványnak vagy interfésznek megfelelően tervezi meg alkatrészét, amely lehetővé teszi a csapat számára az összetevő tervezésének rugalmasságát, ugyanakkor biztosítja, hogy az összes komponens illeszkedjen egymáshoz.
A gépjárműgyártók gyakran ugyanazt az alapstruktúrát használják több különböző modellhez, részben költségszabályozási intézkedésként. Egy ilyen „platform” az információrejtés példája is, hiszen az alaprajz úgy is megépíthető, hogy nem tudjuk, hogy szedánban vagy coupéban használjuk.
Amint az ebből a példából látható, az információk elrejtése rugalmasságot biztosít. Ez a rugalmasság lehetővé teszi a programozó számára, hogy a normál fejlődés során módosítsa a számítógépes program funkcionalitását, miközben a számítógépes program úgy változik, hogy jobban megfeleljen a felhasználók igényeinek. Ha egy számítógépes program jól megtervezett, a forráskód-megoldást az információrejtés elve alapján modulokra bontja, az evolúciós változások sokkal könnyebbek, mivel a változások jellemzően lokálisak, nem pedig globálisak.
Az autók egy másik példát szolgáltatnak erre a vezetőkkel való interakcióban. Szabványos interfészt mutatnak be (pedálok, kerék, váltó, jelzők, mérőműszerek stb.), amelyen az embereket kiképezik és engedéllyel rendelkeznek. Így az embereknek csak meg kell tanulniuk autót vezetni; nem kell teljesen más vezetési módot tanulniuk minden alkalommal, amikor új modellt vezetnek. (Igaz, vannak kézi és automata sebességváltók és egyéb hasonló különbségek, de összességében az autók egységes felületet tartanak fenn.)
Megjegyzések[szerkesztés]
- ↑ Rogers: Encapsulation is not information hiding. JavaWorld, 2001. május 18. (Hozzáférés: 2020. július 20.)
- ↑ a b Booch, Grady. Object-Oriented Analysis and Design with Applications. Addison-Wesley, 51–52. o. (2007. április 25.). ISBN 978-0-201-89551-3
- ↑ Parnas (1972. április 25.). „On the Criteria To Be Used in Decomposing Systems into Modules”. Communications of the ACM 15 (12), 1053–58. o. DOI:10.1145/361598.361623.
- ↑ Scott, Michael L..szerk.: Broy: Programming Language Pragmatics, Third, Morgan Kaufmann Publishers, 173. o.. DOI: 10.1007/978-3-642-59412-0 [2000] (2009). ISBN 978-3-540-43081-0
Hivatkozások[szerkesztés]
- Parnas, David L. (1971. április 25.). „Information Distribution Aspects of Design Methodology”. IFIP Congress 1971 Charles V. Freiman and John E. Griffith and Jack L. Rosenfeld 1: 339–344, North-Holland. doi:10.1184/R1/6606470.V1.
- Parnas, David L..szerk.: Manfred Broy and Ernst Denert: The Secret History of Information Hiding, Software Pioneers. Springer-Verlag Berlin Heidelberg (2002). ISBN 978-0-12-374514-9
In Charles V. Freiman and John E. Griffith and Jack L. Rosenfled (ed). Information Processing, Proceedings of IFIP Congress 1971, Volume 1 - Foundations and Systems, Ljubljana, Jugoslavia, Augus 23-28, 1971. IFIP Congress 1971. Vol. 1. North-Holland. pp. 339-334.
Fordítás[szerkesztés]
Ez a szócikk részben vagy egészben az Information hiding című angol Wikipédia-szócikk ezen változatának 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.