streamalism.org

1. Bemutatkozás

Ebben az oktatóanyagban az Interface Segregation Principle-t tárgyaljuk, amely a SOLID egyik alapelve. Az „I” ábrázolása a „SOLID” -ban az interfész szegregáció egyszerűen azt jelenti, hogy a nagyobb interfészeket kisebbekre kell bontanunk.

Így biztosítva, hogy az osztályok végrehajtásának ne kelljen nem kívánt módszereket megvalósítania.

2. Interfész elkülönítés elve

Ezt az elvet Robert C. Martin határozta meg először:Az ügyfeleket nem szabad arra kényszeríteni, hogy függjenek az általuk nem használt interfészektől“.

Ennek az elvnek az a célja, hogy csökkentse a nagyobb interfészek használatának mellékhatásait azáltal, hogy az alkalmazásfelületeket kisebbekre bontja. Hasonló az egységes felelősség elvéhez, ahol minden osztály vagy interfész egyetlen célt szolgál.

A pontos alkalmazásterv és a megfelelő absztrakció a kulcsa az interfész szegregációs elvének. Bár több időbe és erőfeszítésbe kerül az alkalmazás tervezési szakaszában, és ez növelheti a kód összetettségét, végül rugalmas kódot kapunk.

Megvizsgálunk néhány példát a későbbi szakaszokban, ahol megsértettük az elvet, majd az elv helyes alkalmazásával megoldjuk a problémát.

3. Mintainterfész és megvalósítás

Vizsgáljunk meg egy olyan helyzetet, ahol van egy Fizetés a megvalósítás által használt felület BankPayment:

nyilvános felület Fizetés {void initiatePayments (); Objektum állapota (); List getPayments (); }

És a megvalósítás:

public class BankPayment végrehajtja a fizetést {@Override public void initiatePayments () {// ...} @Orride public Object status () {// ...} @Orride public List getPayments () {// ...}}

Az egyszerűség kedvéért hagyjuk figyelmen kívül ezeket a módszerek tényleges üzleti megvalósítását.

Ez nagyon világos - eddig a megvalósító osztály BankPayment minden módszerre szüksége van a Fizetés felület. Így nem sérti az elvet.

4. Az interfész szennyezése

Ahogy haladunk előre az időben, és újabb funkciók jelennek meg, hozzá kell adni a-t Hiteltörlesztés szolgáltatás. Ez a szolgáltatás is egyfajta Fizetés de van még néhány művelete.

Az új szolgáltatás fejlesztéséhez hozzáadjuk az új módszereket a Fizetés felület:

nyilvános felület Fizetés {// eredeti módszerek ... void intiateLoanSettlement (); void initiateRePayment (); }

Ezután megkapjuk a Hiteltörlesztés végrehajtás:

public class LoanPayment hajtja végre a fizetést {@Override public void initiatePayments () {dobja az új UnsupportedOperationException szolgáltatást ("Ez nem banki fizetés"); } @Orride public Object status () {// ...} @Orride public List getPayments () {// ...} @Orride public void intiateLoanSettlement () {// ...} @Orride public void initiateRePayment () {// ...}}

Most, mivel a Fizetés Az interfész megváltozott, és további módszerek kerültek hozzá, így az összes implementációs osztálynak végre kell hajtania az új módszereket. A probléma az, hogy ezek végrehajtása nem kívánt, és sok mellékhatáshoz vezethet. Itt a Hiteltörlesztés megvalósítási osztálynak végre kell hajtania a initiatePayments () tényleges szükség nélkül erre. És így, az elv sérül.

Szóval, mi történik a miénkkel BankPayment osztály:

public class BankPayment végrehajtja a fizetést {@Override public void initiatePayments () {// ...} @Orride public Object status () {// ...} @Override public List getPayments () {// ...} @Override public void intiateLoanSettlement () {dobjon új UnsupportedOperationException ("Ez nem hitelkifizetés"); } @Orride public void initiateRePayment () {dobj új UnsupportedOperationException ("Ez nem hitelkifizetés"); }}

Vegye figyelembe, hogy a BankPayment a megvalósítás most már bevezette az új módszereket. És mivel nincs szüksége rájuk, és nincs logikája számukra, az az csak dob egy UnsupportedOperationException. Itt kezdjük megsérteni az elvet.

A következő részben meglátjuk, hogyan oldhatjuk meg ezt a problémát.

5. Az elv alkalmazása

Az utolsó szakaszban szándékosan szennyeztük az interfészt és megsértettük az elvet. Ebben a szakaszban megvizsgáljuk, hogyan lehet az elv megsértése nélkül hozzáadni az új funkciót a hitelfizetéshez.

Bontjuk le az egyes fizetési módok felületét. A jelenlegi helyzet:

Figyeljük meg az osztálydiagramon, és utalva a korábbi szakaszban található interfészekre, hogy a állapot() és getPayments () módszerekre van szükség mindkét megvalósításban. Másrészről, initiatePayments () csak ben szükséges BankPayment, és a initiateLoanSettlement () és initiateRePayment () módszerek csak a Hiteltörlesztés.

Ezzel rendezve bontsuk szét az interfészeket és alkalmazzuk az Interfész szegregáció elvét. Így most van egy közös felületünk:

nyilvános felület Fizetés {Object status (); List getPayments (); }

És még két interfész a kétféle fizetéshez:

nyilvános felület A Bank kiterjeszti a Fizetést {void initiatePayments (); }

nyilvános felület A kölcsön meghosszabbítja a Fizetést {void intiateLoanSettlement (); void initiateRePayment (); }

És a megfelelő megvalósítások, kezdve BankPayment:

public class BankPayment implementálja a Bank {@Orride public void initiatePayments () {// ...} @Orride public Object status () {// ...} @Orride public List getPayments () {// ...}}

És végül átdolgozott Hiteltörlesztés végrehajtás:

public class LoanPayment hajtja végre a hitelt {@Orride public void intiateLoanSettlement () {// ...} @Orride public void initiateRePayment () {// ...} @Orride public Object status () {// ...} @Override public list getPayments () {// ...}}

Most nézzük át az új osztálydiagramot:

Mint láthatjuk, az interfészek nem sértik az elvet. A megvalósításoknak nem kell üres módszereket megadniuk. Ez tisztán tartja a kódot és csökkenti a hibák esélyét.

6. Következtetés

Ebben az oktatóanyagban egy egyszerű forgatókönyvet néztünk meg, ahol először letértünk az interfész szegregációs elvének követéséről, és megláttuk az eltérés okozta problémákat. Ezután megmutattuk, hogyan kell helyesen alkalmazni az elvet e problémák elkerülése érdekében.

Abban az esetben, ha olyan szennyezett régebbi interfészekkel van dolgunk, amelyeket nem tudunk módosítani, az adapterminta jól jöhet.

Az interfész szegregáció elve fontos koncepció az alkalmazások tervezése és fejlesztése során. Ennek az elvnek a betartása segít elkerülni a több felelősséggel járó duzzadt interfészeket. Ez végül segít bennünket az egységes felelősség elvének követésében is.

Mint mindig, a kód elérhető a GitHubon.