A Liskov-helyettesítés elve, harmadik SOLID-elv

A gyermekosztályok soha nem befolyásolhatják vagy módosíthatják a leket defia szülő osztály típusának utasításai.

Ennek az elvnek az elvét Barbara Liskov vezette be egy 1987-es konferencia vitaindító előadásában, majd 1994-ben Jannette Winggel közösen publikálták. defiaz eredeti szöveg a következő:

Legyen q (x) kimutatható tulajdonság a T típusú x objektumokon. Ezután q (y) legyen kimutatható az S típusú y objektumok esetében, ahol S a T altípusa.

Ezt követően Robert C. Martin SOLID-elvei megjelentetésével Agile Software Development, Principles, Patterns and Practices című könyvében, majd az Agile Principles, Patterns and Practices in C# című könyv C# verziójában újra megjelentették a defiLiskov-helyettesítési elvként vált ismertté.

Ez elvezet bennünket a defiRobert C. Martin által adott információ: Az altípusoknak cserélhetőknek kell lenniük az alaptípusaikkal.

Egyszerűbben, egy alosztálynak felül kellene írnia a szülő osztály módszereit oly módon, hogy az ne tönkretegye a funkcionalitást az ügyfél szempontjából. Itt van egy egyszerű példa a koncepció bemutatására.

osztály Jármű {

    function startEngine () {

        // Alapértelmezett motorindítási funkció

    }

 

    függvény gyorsít () {

        // Alapértelmezett gyorsítási funkció

    }

}

Adott egy járműosztály - absztrakt lehet - és két megvalósítás:

osztályú autó meghosszabbítja a járművet {

    function startEngine () {

        $ this-> engIgnition ();

        szülő :: startEngine ();

    }

 

    privát funkció engIgnition () {

        Gyújtási eljárás

    }

}

 

az ElectricBus osztály meghosszabbítja a járművet

    függvény gyorsít () {

        $ ez-> növeliFeszültség ();

        $ this-> connectIndividualEngines ();

    }

 

    privát funkció növeléseFeszültség () {

        // Elektromos logika

    }

 

    privát függvény connectIndividualEngines () {

        // Kapcsolódási logika

    }

}

osztály Pilóta

    függvény go (Jármű $ v) {

        $ v-> startEngine ();

        $ v-> felgyorsít ();

    }

}

Az ügyfélosztálynak képesnek kell lennie mindkettő használatára, ha tudja használni a Járművet.

Ezzel eljuthatunk a sablon módszer tervezési mintájának egyszerű megvalósításához, amint azt az OCP-ben használtuk.

Érdekelheti a második SOLID elv is: https: //bloginnovazione.hu / nyitott-zárt-második-szilárd-elv / 3906 /

Az Open / Closed elvvel szerzett korábbi tapasztalataink alapján arra a következtetésre juthatunk, hogy a Liskov-szubsztitúciós elv szorosan összefügg az OCP-vel. Valójában "az LSP megsértése az OCP látens megsértése" (Robert C. Martin), a Template Method Design Pattern pedig az LSP tiszteletben tartásának és megvalósításának klasszikus példája, amely viszont az egyik megoldás a megfelelésre az OCP-vel.

Példa az LSP megsértésére

osztály Téglalap {

    privát $ topLeft;

    privát $ szélesség;

    privát $ magasság;

 

    public function setHeight ($ height) {

        $ ez-> magasság = $ magasság;

    }

 

    nyilvános funkció getHeight () {

        return $ this-> magasság;

    }

 

    nyilvános függvény setWidth ($ width) {

        $ this-> width = $ width;

    }

 

    nyilvános függvény getWidth () {

        return $ this-> width;

    }

}

Kezdjük egy alapvető geometriai alakzattal, egy téglalapkal. Ez csak egy egyszerű adatobjektum, szélességgel és magassággal rendelkező beállítókkal és mérőórákkal. Képzelje el, hogy alkalmazásunk működik, és már több kliensen van telepítve. Most új funkcióra van szükségük. Képesnek kell lenniük a négyzetek manipulálására.

A való életben, a geometriában a négyzet a téglalap sajátos alakja. Így megpróbálhatunk egy Square osztályt megvalósítani, amely kiterjeszti a Rectangle osztályt. Gyakran mondják, hogy a gyermek osztály szülő osztály, és ez a kifejezés legalább első pillantásra megfelel az LSP-nek is.

osztály Négyzet nyúlik téglalap {

    public function setHeight ($ value) {

        $ this-> width = $ value;

        $ ez-> magasság = $ érték;

    }

 

    public function setWidth ($ value) {

        $ this-> width = $ value;

        $ ez-> magasság = $ érték;

    }

}

A négyzet egyenlő szélességű és magasságú téglalap, és furcsa megvalósítást tehetünk, mint az előző példában. Mindkét szettet felülírhatjuk, hogy beállítsuk a magasságot és a szélességet is. De hogyan befolyásolja ez az ügyfél kódját?

osztály Ügyfél {

    function areaVerifier ($ r téglalap) {

        $ r-> setWidth (5);

        $ r-> setHeight (4);

        ha ($ r-> terület ()! = 20) {

            dobja az új Kivételt ('Rossz terület!');

        }

        Return true;

    }

}

Elképzelhető, hogy van egy kliensosztály, amely ellenőrzi a téglalap területét, és kivételt dob, ha az téves.

funkcióterület () {

    adja vissza ezt: $ this-> width * $ this-> height;

}

Nyilvánvalóan felvettük a fenti módszert a Téglalap osztályba, hogy biztosítsuk a területet.

Az LspTest osztály kiterjeszti a PHPUnit_Framework_TestCase {

    function testRectangleArea () {

        $ r = új téglalap ();

        $ c = új kliens ();

        $ this-> assertTrue ($ c-> areaVerifier ($ r));

    }

}

És létrehoztunk egy egyszerű tesztet úgy, hogy egy üres téglalap objektumot küldtünk a terület-ellenőrzőnek, és a teszt sikeres. Ha osztályunk Négyzete az defihelyesen van elküldve, ha elküldi az ügyfél területére, aVerifier() nem tönkreteheti a működését. Végül is a négyzet minden matematikai értelemben téglalap. De a mi osztályunk?

function testSquareArea () {

    $ r = új négyzet ();

    $ c = új kliens ();

    $ this-> assertTrue ($ c-> areaVerifier ($ r));

}

Tehát a Négyzet osztályunk mégsem egy téglalap. Megszegi a geometria törvényeit. Nem működik, és sérti a Liskov-helyettesítés elvét.

Ercole Palmeri