Прынцып замены Ліскава, трэці прынцып ЦВЯРДЫ

Даччыныя класы ніколі не павінны ўплываць або змяняць файлы defiаператары тыпу бацькоўскага класа.

Канцэпцыя гэтага прынцыпу была прадстаўлена Барбарай Ліскоў у праграмным дакладзе канферэнцыі ў 1987 годзе і пазней апублікавана ў артыкуле разам з Джанет Уінг у 1994 годзе. defiарыгінал такі:

Няхай q (x) - уласцівасць, якое можна прадэманстраваць, на аб'ектах x тыпу T. Тады q (y) павінна быць дэманстратыўнай для аб'ектаў y тыпу S, дзе S - падтып T.

Пазней, з публікацыяй прынцыпаў SOLID Роберта К. Марціна ў яго кнізе Agile Software Development, Principles, Patterns, and Practices, а затым перавыдадзенай у версіі C# кнігі Agile Principles, Patterns, and Practices in C#, defiстаў вядомы як прынцып замены Ліскова.

Гэта падводзіць нас да defiінфармацыя, прадстаўленая Робертам К. Марцінам: Падтыпы павінны быць заменены асноўнымі тыпамі.

Прасцей кажучы, падклас павінен быў бы перавызначыць метады бацькоўскага класа такім чынам, каб не парушаць функцыянальнасць з пункту гледжання кліента. Вось просты прыклад для дэманстрацыі канцэпцыі.

клас транспартны сродак {

    функцыя startEngine () {

        // Функцыя запуску рухавіка па змаўчанні

    }

 

    функцыя accelerate () {

        // Функцыя паскарэння па змаўчанні

    }

}

Улічваючы клас Vehicle - ён можа быць абстрактным - і дзве рэалізацыі:

клас Аўтамабіль пашырае транспартны сродак {

    функцыя startEngine () {

        $ гэта-> займацца запальваннем ();

        бацька :: startEngine ();

    }

 

    прыватная функцыя engaIgnition () {

        // Працэдура запальвання

    }

}

 

клас ElectricBus пашырае транспартны сродак {

    функцыя accelerate () {

        $ this-> павялічыцьнапружанне ();

        $ this-> connectIndividualEngines ();

    }

 

    прыватная функцыя павялічыцьнапружанне () {

        // Электрычная логіка

    }

 

    прыватная функцыя connectIndividualEngines () {

        // Логіка злучэння

    }

}

клас Кіроўца {

    функцыя go (Vehicle $ v) {

        $ v-> startEngine ();

        $ v-> паскарэнне ();

    }

}

Кліенцкі клас павінен мець магчымасць выкарыстоўваць і тое, і іншае, калі можа выкарыстоўваць Vehicle.

Што падводзіць нас да простай рэалізацыі шаблону дызайну метадаў шаблонаў, як мы выкарыстоўвалі яго ў OCP.

Вас таксама можа зацікавіць другі прынцып SOLID: https: //bloginnovazione.en / open-closed-second-solid-principle / 3906 /

Зыходзячы з нашага папярэдняга досведу з прынцыпам Open / Closed, мы можам зрабіць выснову, што прынцып замены Ліскава цесна звязаны з OCP. На самай справе, "парушэнне LSP - гэта латэнтнае парушэнне OCP" (Роберт К. Марцін), а шаблон шаблону дызайну - класічны прыклад павагі і ўкаранення LSP, што, у сваю чаргу, з'яўляецца адным з рашэнняў для адпаведнасці з OCP.

Прыклад парушэння LSP

клас Прамавугольнік {

    прыватны $ topLeft;

    прыватная $ шырыня;

    прыватная вышыня $;

 

    публічная функцыя setHeight ($ height) {

        $ this-> вышыня = $ вышыня;

    }

 

    грамадская функцыя getHeight () {

        вярнуць $ this-> вышыня;

    }

 

    адкрытая функцыя setWidth ($ шырыня) {

        $ this-> шырыня = $ шырыня;

    }

 

    публічная функцыя getWidth () {

        вярнуць $ this-> width;

    }

}

Пачнем з асноўнай геаметрычнай фігуры - прамавугольніка. Гэта проста просты аб'ект дадзеных з устаноўшчыкамі і атрымальнікамі шырыні і вышыні. Уявіце, што наша прыкладанне працуе і ўжо разгорнута на некалькіх кліентах. Цяпер ім патрэбна новая функцыя. Яны павінны ўмець маніпуляваць квадратамі.

У рэальным жыцці ў геаметрыі квадрат - гэта пэўная форма прамавугольніка. Такім чынам, мы маглі б паспрабаваць рэалізаваць клас Square, які пашырае клас Rectangle. Часта кажуць, што дзіцячы клас - гэта бацькоўскі клас, і гэты выраз таксама адпавядае LSP, па меншай меры, на першы погляд.

клас Square працягвае прамавугольнік {

    публічная функцыя setHeight ($ значэнне) {

        $ this-> width = $ value;

        $ гэта-> вышыня = $ значэнне;

    }

 

    публічная функцыя setWidth ($ value) {

        $ this-> width = $ value;

        $ гэта-> вышыня = $ значэнне;

    }

}

Квадрат - гэта прамавугольнік з аднолькавай шырынёй і вышынёй, і мы маглі б зрабіць дзіўную рэалізацыю, як у папярэднім прыкладзе. Мы маглі б перавызначыць абодва ўстаноўкі, каб усталяваць і вышыню, і шырыню. Але як гэта паўплывае на кліенцкі код?

кліент класа {

    функцыя areaVerifier (Прамавугольнік $ r) {

        $ r-> setWidth (5);

        $ r-> setHeight (4);

        калі ($ r-> вобласць ()! = 20) {

            кінуць новае выключэнне ('Дрэнная вобласць!');

        }

        вяртае ісціну;

    }

}

Магчыма мець кліенцкі клас, які правярае плошчу прамавугольніка і выдаляе выключэнне, калі яно няправільнае.

вобласць функцыі () {

    вярнуць $ this-> шырыня * $ this-> вышыня;

}

Мы відавочна дадалі вышэйзгаданы спосаб у наш клас Rectangle для прадастаўлення вобласці.

клас LspTest пашырае PHPUnit_Framework_TestCase {

    функцыя testRectangleArea () {

        $ r = новы прастакутнік ();

        $ c = новы кліент ();

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

    }

}

І мы стварылі просты тэст, адправіўшы пусты прамавугольны аб'ект у праграму праверкі вобласці, і тэст прайшоў. Калі наш клас Плошча defiскончаны правільна, адпраўка яго ў areaVerifier() кліента не павінна парушаць яго функцыянальнасць. У рэшце рэшт, квадрат - гэта прастакутнік ва ўсіх матэматычных сэнсах. Але ці наш гэта клас?

функцыя testSquareArea () {

    $ r = новы квадрат ();

    $ c = новы кліент ();

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

}

Такім чынам, наш клас Square не з'яўляецца Rectangle у рэшце рэшт. Гэта парушае законы геаметрыі. Гэта не атрымліваецца і парушае прынцып замены Ліскова.

Ercole Palmeri