Interfészszegregációs alapelv
A szoftverfejlesztés területén az interfészszegregációs elv (angolul: Interface Segregation Principle, ISP) kimondja, hogy egyetlen klienst sem szabad arra kényszeríteni, hogy olyan metódusoktól függjön, amelyeket nem használ.[1] Eredeti angol megfogalmazása: „No client should be forced to depend on methods it does not use”, azaz „Egy kliens se legyen rákényszerítve, hogy olyan metódusoktól függjön, amiket nem is használ”.
Az ISP a nagyon nagy interfészeket kisebbekre és sokkal specifikusabbakra osztja fel, így a klienseknek csak azokról a metódusokról kell tudniuk, amelyeket használnak. Az ilyen leegyszerűsített interfészeket szerepinterfészeknek is nevezik (angolul role interface).[2] Az ISP célja, hogy a rendszer maradjon független, így könnyebben refaktorálható, megváltoztatható és újratelepíthető. Az ISP a SOLID objektumorientált tervezés öt alapelvének egyike (hasonlóan a GRASP magas kohéziós alapelvéhez).[3]
Az objektumorientált tervezés fontossága[szerkesztés]
Az objektumorientált tervezésben az interfészek absztrakciós rétegeket biztosítanak, amelyek egyszerűsítik a kódot, és indirektté teszik a kapcsolatot az implementációkkal, függőségekkel.
A kiáltványt aláíró számos szoftverszakértő szerint a jól felépített és érthetően megírt szoftverkód szinte ugyanolyan fontos, mint maga a megfelelően működő szoftver.[4] Az interfészek általában jól használhatók arra, hogy érthetővé tegyék a szoftver működési elvét.
Ha egy rendszer nagyon sok belső összekapcsolódást tartalmaz, akkor egy kisebb módosítás is számos további változtatást tesz szükségessé a rendszer más helyein.[1] Interfészek intenzív használatával ez elkerülhető.
Eredete[szerkesztés]
Az ISP-t először Robert C. Martin használta és fogalmazta meg, mikor a Xeroxnak folytatott tanácsadást. A Xerox új nyomtatórendszert hozott létre, amely különféle feladatokat volt képes elvégezni, például tűzést és a faxolást. A szoftver növekedésével a módosítások egyre nehezebbé váltak, végül a legkisebb változtatás is körülbelül egy órás telepítési ciklussal járt, egyre nehezebbé téve a fejlesztést.
A tervezési probléma az volt, hogy majdnem az összes feladat egyetlen közös, Job nevű osztályt használt. Amikor nyomtatási, tűzési vagy bármilyen egyéb feladatot kellett elvégezni, a kliens minden esetben közvetlenül a Job felé kezdeményezett hívást. A Job emiatt a különféle feladatokhoz kapcsolható összes metódust tartalmazta (az ilyen monumentális osztályokat kövér osztályoknak is nevezik). A hívó felelőssége volt, hogy csak az adott feladathoz kapcsolódó metódusokat használja.
Gyakran előfordul, hogy egy eredetileg sovány (legfejlebb néhány száz soros) osztály a fejlesztés során elkezd hízni, egyre több felelősséget lát el, és a végén egy kövér (sok ezer soros) osztály jön létre. A kövér osztályokat az egy felelősség egy osztály elv (SRP) persze eleve kizárja. Ha viszont már van egy ilyen osztályunk (pl. legacy kódból), akkor egyszerűbb (az azonos szerephez tartozó metódusokat összefogó) interfészeket definiálni fölé, mint a kövér osztályt ténylegesen szétszedni kisebbekre.[5] Ezután bármely kliens számára elég a szerepének megfelelő interfészt kiadni.
A Martin által javasolt megoldást ma interfészszegregációs elvnek (angolul: Interface Segregation Principle) nevezik.
A Xerox szoftverének esetében bevezettek egy interfész-réteget a Job osztály és a kliensek közé (lád még: függőség befecskendezésének elve). Így létrejött például a tűzéshez illetve a nyomtatáshoz tartozó metódusokat tartalmazó interfész, melyeket a tűzést illetve nyomtatást elrendelő kliensek használhattak (a Job osztály közvetlen hívása helyett). A háttérben mindezeket az interfészeket a Job osztály implementálta, de ehhez a klienseknek nincs közük (így már tulajdonképpen az implementáció refaktorálása is kockázatmentesen elvégezhetővé vált).
Az interfészszegregációs alapelv megsértésének tipikus esetét az Agile Software Development: Principles, Patterns and Practices (PPP)[1] „ATM tranzakciós példa” című része valamint Robert C. Martinnak a kifejezetten az ISP-ről (Interface Segregation Principle) írt cikke ismerteti.[6] Ez a példa egy ATM automata felhasználói felületéről szól, amely kezeli az összes kérést, például a befizetési, illetve a visszavonási kérelmet; valamint arról, hogyan kell szétbontani ezt a felületet specifikusabb interfészekre.
Jegyzetek[szerkesztés]
- ↑ a b c Martin, Robert (2002). Agile Software Development: Principles, Patterns, and Practices. Pearson Education.
- ↑ Role Interface
- ↑ David Hayden, Interface-Segregation Principle (ISP) - Principles of Object-Oriented Class Design'. [2010. augusztus 20-i dátummal az eredetiből archiválva]. (Hozzáférés: 2009. november 7.)
- ↑ Manifesto of Software Craftsmanship
- ↑ http://aries.ektf.hu/~hz/pdf-tamop/pdf-xx/ProgTechJegyzet.1.1.6.pdf
- ↑ Robert C. Martin,The Interface Segregation Principle, C++ Report, June 1996
Fordítás[szerkesztés]
Ez a szócikk részben vagy egészben az Interface segregation principle 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.
További információk[szerkesztés]
- OOP alapelvei Leírások és linkek a SOLID-ról szóló részletes cikkekhez.
- Dr Kusper Gábor - Jegyzet a projekt labor című tárgyhoz[1]
- ↑ Dr Kusper Gábor- Jegyzet a projekt labor című tárgyhoz. (Hozzáférés: 2020. május 4.)