Ugrás a tartalomhoz

Csomagolási elv

A Wikipédiából, a szabad enciklopédiából
A lap korábbi változatát látod, amilyen Fausto (vitalap | szerkesztései) 2020. június 20., 15:18-kor történt szerkesztése után volt. Ez a változat jelentősen eltérhet az aktuális változattól. (Programozási alapfogalmak kategória hozzáadva (a HotCattel))

A programozásban a csomagolási elveket a nagyobb rendszerekben lévő osztályok rendszerezésére használjuk, azért, hogy könnyebben kezelhetővé és rendezettebbé tegyük azokat. Ezek az elvek segítséget nyújtanak, hogy egyes osztályoknak melyik csomagba kell kerülniük (csomagok összetartozása), és hogy ezek a csomagok mégis hogyan kapcsolódnak egymáshoz (csomagkapcsolat). Továbbá ezek az alapelvek tartalmaznak szoftvercsomag-mutatókat is, melyek a függőségi struktúra számszerűsítésében nyújtanak segítséget, úgy, hogy különböző és/vagy pontosabb rálátást adnak az osztályok és csomagok teljes szerkezetére.

Áttekintés

Csomagkohéziós elvek

Reuse-release Equivalence Principle (REP)
A "REP" lényegében azt jelenti, hogy egy csomagot olyan osztályokkal kell létrehozni, melyek újrafelhasználhatóak. - „Vagy az összes csomagban lévő osztály újrafelhasználható, vagy egyik sem”. Az osztályoknak ugyanabból a családból kell származniuk. Azokat az osztályokat, amelyek nem kapcsolódnak a csomag céljához, nem kell az adott csomagba helyeznünk. Egy olyan csomag bizonyul a leghasznosabbnak és legjobban újrafelhasználhatónak, ami újrafelhasználható osztályok családjával lett létrehozva.
Common-Reuse Principle (CRP)
A "CRP" kimondja, hogy ugyanabba a csomagba kell tartozniuk azoknak az osztályoknak, amelyek együttesen lesznek újrafelhasználva. Ez az elv segítséget nyújt annak eldöntésére, hogy az egyes osztályok melyik csomagba tartoznak. A csomagtól függően biztosra akarunk menni, hogy az osztályok elválaszthatatlanok és egymástól kölcsönösen függenek, ami akkor lehet hasznos, amikor a csomagunkba egy nem oda tartozó osztályt szeretnénk behúzni.
Common-Closure Principle (CCP)
A "CCP" kimondja, hogy egy csomagnak maximum egy oka lehet a változásra. Ha egy olyan alkalmazásban történik változás, amely számos csomagtól függ, akkor ideális esetben azt szeretnénk, hogy ezek a változások csak egy csomagot érintsenek. Ez az elv segítséget nyújt azon osztályok azonosításában, amelyek valószínűleg változni fognak, és így ezeket az osztályokat ugyanahhoz a csomaghoz tudjuk hozzárendelni. Ha az osztályok szorosan kapcsolódnak egymáshoz, akkor szintén ugyanahhoz a csomaghoz kell tartozniuk.

Csomag-összekapcsolási elvek

Acyclic Dependencies Principle (ADP)
Egy fejlesztési ciklusban, melyben egyszerre több fejlesztő dolgozik együtt, az együttműködés és az integráció fokozatos kell hogy legyen. Az "ADP" kimondja, hogy egy függőségi struktúra nem tartalmazhat kört/ciklust. Ha egy növekményes kiadás történik a fejlesztés során, a többi programozó ezt alkalmazhatja és építkezhet rá.
Stable-Dependencies Principle (SDP)
A fejlesztői környezet természetéből adódó dizájnok folyamatosan változnak. Ebből kifolyólag a csomag dizájnoknak támogatniuk kell a változást. Az "SDP" kimondja, hogy bármely csomag, amelynek ezt a változékony tulajdonságát megszeretnénk tartani, nem függhet olyan csomagtól, amit nehéz változtatni.
Stable-Abstractions Principle (SAP)
Az "SAP" kimondja, hogy egy stabil/állandó csomagnak absztraktnak is kell lennie, emiatt a stabilitása nem gátolja meg abban, hogy bővíthető maradjon. Továbbá kijelenti, hogy egy instabil csomagnak konkrétnak/kötöttnek kell lennie, mivel ez lehetővé teszi, hogy a benne lévő kód könnyen változtatható legyen.

Kapcsolódó szócikk

Források

Fordítás

  • Ez a szócikk részben vagy egészben a Package principles 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.