Princip supstitucije Liskova, treći SOLIDNI princip

Podređene klase nikada ne bi trebalo da utiču na datoteke ili da ih menjaju defiiskazi tipa roditeljske klase.

Koncept ovog principa predstavila je Barbara Liskov na konferenciji 1987., a kasnije je objavljena u radu zajedno sa Jannette Wing 1994. godine. defioriginal je sljedeci:

Neka je q (x) dokazljivo svojstvo na objektima x tipa T. Tada bi q (y) trebalo biti dokazljivo za objekte y tipa S gdje je S podtip T.

Kasnije, s objavljivanjem principa SOLID Roberta C. Martina u njegovoj knjizi Agilni razvoj softvera, principi, obrasci i prakse, a zatim ponovo objavljena u C# verziji knjige Agile Principles, Patterns, and Practices in C#, deficija je postala poznata kao princip zamjene Liskov.

Ovo nas dovodi do defiinformacije koje je dao Robert C. Martin: Podtipovi se moraju zamijeniti osnovnim tipovima.

Jednostavnije, potklasa bi trebala nadjačati metode roditeljske klase na način koji ne narušava funkcionalnost sa stanovišta kupca. Evo jednostavnog primjera za demonstraciju koncepta.

klase Vozilo {

    funkcija startEngine () {

        // Zadana funkcionalnost pokretanja motora

    }

 

    funkcija accelerate () {

        // Zadana funkcionalnost ubrzanja

    }

}

S obzirom na klasu vozila - može biti apstraktna - i dvije implementacije:

klasa Car produžuje vozilo {

    funkcija startEngine () {

        $ this-> engaggnition ();

        nadređeni :: startEngine ();

    }

 

    privatna funkcija engaIgnition () {

        // Postupak paljenja

    }

}

 

klasa ElectricBus proširuje vozilo {

    funkcija accelerate () {

        $ ovo-> povećajVoltage ();

        $ ovo-> connectIndividualEngines ();

    }

 

    privatna funkcija povećanjeVoltage () {

        // Električna logika

    }

 

    privatna funkcija connectIndividualEngines () {

        // Logika veze

    }

}

klasa Vozač {

    funkcija go (vozilo $ v) {

        $ v-> startEngine ();

        $ v-> ubrzati ();

    }

}

Klijentska klasa bi trebala biti u mogućnosti koristiti oboje ako može koristiti vozilo.

Što nas dovodi do jednostavne implementacije obrasca dizajna metode predloška kakav smo koristili u OCP-u.

Možda će vas zanimati i drugi SOLID princip: https://bloginnovazione.en / otvoreno-zatvoreno-drugi-čvrsti princip / 3906 /

Na osnovu našeg prethodnog iskustva s otvorenim / zatvorenim principom, možemo zaključiti da je Liskov princip supstitucije usko povezan s OCP-om. U stvari, „kršenje LSP-a latentno je kršenje OCP-a“ (Robert C. Martin), a obrazac dizajna metode predloška klasičan je primjer poštivanja i provedbe LSP-a, što je pak jedno od rješenja za usklađivanje sa OCP.

Primjer kršenja LSP

klasa Pravokutnik {

    private $ topLeft;

    private $ width;

    private $ height;

 

    javna funkcija setHeight ($ height) {

        $ ovo-> visina = $ visina;

    }

 

    javna funkcija getHeight () {

        vrati $ this-> height;

    }

 

    javna funkcija setWidth ($ width) {

        $ ovo-> širina = $ širina;

    }

 

    javna funkcija getWidth () {

        vrati $ this-> width;

    }

}

Počnimo s osnovnim geometrijskim oblikom, pravougaonikom. To je samo jednostavan objekt podataka sa setterima i getterima za širinu i visinu. Zamislite da naša aplikacija radi i da je već postavljena na nekoliko klijenata. Sada im je potrebna nova karakteristika. Moraju upravljati trgovima.

U stvarnom životu, u geometriji, kvadrat je poseban oblik pravokutnika. Tako bismo mogli pokušati implementirati klasu Square koja proširuje klasu Rectangle. Često se kaže da je dječja klasa roditeljska klasa, a ovaj izraz također odgovara LSP, barem na prvi pogled.

klasa Square extends Rectangle {

    javna funkcija setHeight ($ vrijednost) {

        $ this-> width = $ value;

        $ ovo-> visina = $ vrijednost;

    }

 

    javna funkcija setWidth ($ value) {

        $ this-> width = $ value;

        $ ovo-> visina = $ vrijednost;

    }

}

Kvadrat je pravokutnik jednake širine i visine i mogli bismo napraviti čudnu implementaciju kao u prethodnom primjeru. Mogli bismo nadjačati oba postavljača kako bi postavili i visinu i širinu. Ali kako će ovo utjecati na klijentski kod?

klasa klijent {

    function areaVerifier (pravokutnik $ r) {

        $ r-> setWidth (5);

        $ r-> setHeight (4);

        if ($ r-> area ()! = 20) {

            baciti novi izuzetak ('Loše područje!');

        }

        povratak istinit;

    }

}

Zamislivo je imati klijentsku klasu koja provjerava područje pravokutnika i donosi izuzetak ako je pogrešan.

područje funkcije () {

    vrati $ this-> width * $ this-> height;

}

Očito smo dodali gornju metodu u našu klasu Rectangle da bismo osigurali područje.

klasa LspTest proširuje PHPUnit_Framework_TestCase {

    function testRectangleArea () {

        $ r = novi pravokutnik ();

        $ c = novi klijent ();

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

    }

}

I kreirali smo jednostavan test slanjem praznog pravougaonog objekta u provjeru područja i test je prošao. Ako je naš razred Kvadrat defizavršeno ispravno, slanje u klijentovu oblastVerifier() ne bi trebalo da naruši njegovu funkcionalnost. Na kraju krajeva, kvadrat je pravougaonik u svakom matematičkom smislu. Ali da li je to naša klasa?

funkcija testSquareArea () {

    $ r = novi kvadrat ();

    $ c = novi klijent ();

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

}

Dakle, naša Square klasa ipak nije Rectangle. Krši zakone geometrije. Ne uspijeva i krši princip zamjene Liskova.

Ercole Palmeri