interface Foo {} class FooImpl implements Foo {} interface Bar { public function bar(Foo $data); } class BarImpl implements Bar { public function bar(FooImpl $data) { } }

а тут?

Потому что ты усилил постусловия. Теперь если какой то другой класс будет завязан на interface то может быть непредсказуемое поведение

p.s. то что в php оба эти примера пока не заведутся - это дело третье

Потому что ты усилил постусловия. Теперь если какой то другой класс будет завязан на interface то может быть непредсказуемое поведение

LSP как раз таки разрешает усиливать пост условия

require no more, promise no less

если твой клиент был завязан на что-то общее а ты вернул что-то более конкретное - клиент это сломать не должно

require no more, promise no less

есть еще robustness principle

там где будь либерален к тому что ты принимаешь на вход и будь консервативен в том что выплевываешь на выход

если твой клиент был завязан на что-то общее а ты вернул что-то более конкретное - клиент это сломать не должно

и нарушением LSP было бы изменить, допустим, колво аргументов конкретного метода в наследнике

так?

если они обазятельны

так, конечно, язык не позволит, но тем не менее

ну да

так, конечно, язык не позволит, но тем не менее

именно это и есть "статический анализ компилятора"

а дальше весь вопрос умеет ли твой язык в ковариантность/контрвариантность типов. Java и C# умеют. PHP пока нет но обещают сделать

пресловутое сужение возвращаемого типа?

да

и расширение входящего типа

вроде ведь rfc завернули

вроде ведь rfc завернули

ммм.... нет

или просто подняли бучу по его поводу

если твой клиент был завязан на что-то общее а ты вернул что-то более конкретное - клиент это сломать не должно

Да тут я понял ок

или просто подняли бучу по его поводу

там была RFC по поводу "опускания" типа в наследнике и его как раз приняли. Морисон говорил что он в этом году хочет запилить. А нормальной RFC пока небыло

а, вспомнил, да

Ну а с этими прямоугольниками. Square { construct(x) { parent::construct(x,x) } }

Да тут я понял ок

тот факт что php не позволяет тебе делать наследников нарушающих LSP на примитивном уровне уже говорит о первом пункте из твоего вопроса

Ну а с этими прямоугольниками. Square { construct(x) { parent::construct(x,x) } }

ну тут нет нарушения

нарушения пойдут когда у тебя появятся setSize(width, height)

потому что квадрат и прямоугльник в твоем случае представляют разные типы объектов у которых различается поведение в контексте размеров.

function setWidth(x) { $this-x = $x; $this->setHeight(x) }

и расширение входящего типа

стоп, так расширение входящего и сужение исходящего типа нарушает LSP? я думал наоборот. или я вас не так понял?

у дяди боба ж был пример - что мол "адвакаты по бракоразводному процессу представляют мужа и жену, но не обязаны являться ими"

вот нарушение по дяде бобу

стоп, так расширение входящего и сужение исходящего типа нарушает LSP? я думал наоборот. или я вас не так понял?

нет, как раз таки это позволителььно. Нарушение это когда наоборот

а, всё хорошо, значит не так понял. а то я аж напрягся.

а что насчёт контрактов на значение аргумента? ... это никаким статическим анализатором не отловишь interface Foo { public function bar(int $a); } class FooImpl implements Foo { /** * @throws NegativeArgumentException * @param int $a */ public function bar(int $a) { // ... } }

вот нарушение по дяде бобу

ну и такие вот штуки статический анализ не выявит

Ну вот я к этому и веду

Что ответ не подходит

а что насчёт контрактов на значение аргумента? ... это никаким статическим анализатором не отловишь interface Foo { public function bar(int $a); } class FooImpl implements Foo { /** * @throws NegativeArgumentException * @param int $a */ public function bar(int $a) { // ... } }

в java есть возможность @throws на уровне интерфейса объявить

Что ответ не подходит

ну там же нет "нет ни одного правильного?"

ну тогда про TDD

все остальное точно чушь

все остальное точно чушь

Весь тест один большой фарс

Но сдать надо

в java есть возможность @throws на уровне интерфейса объявить

нет, понятно что можно объявить) ... но мы же "хотим" нарушить LSP ... был интерфейс, мы сделали реализацию, в которой нарушили контракт ... с точки зрения языка всё ок ... статический анализатор не помог

Ну вот я к этому и веду

LSP про поведение. Увы невозможно в наших языках выразить явно контракты. Ну и не забывай что есть еще инварианты которые ты никак статически не проверишь адекватно

Но сдать надо

Вам поди еще за это зарплату обещают повысить ?

Вам поди еще за это зарплату обещают повысить ?

Понизить могут :)

ну вот смотри

там тогда остается только TDD позволяет контролировать type errors в языках с динамической системой типов

ну и тут тоже можно придраться что TDD не про это, но дядя боб об этом писал потому можно

http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html

Да я читал

про type wars

я пробовал этот вариант

> Using TDD, the Smalltalk programmers were assured that the missile would reach it’s target. In fact, they had much more assurance than the type-checking of the C++ or Java compiler could provide.

да

я был рад 3 попытки назад

Когда наткнулся на эту статью

Но нет

ну значит нет ни одного верного варианта а автор теста не шарит

уволняйся

или смирись и будь выше этого

Кароче либо статический анализ или tdd

ок

ERROR: S client not available

чет скучный у вас тут срач

Давайте дальше

:)

Давайте дальше

не давай ты сам

https://t.me/oop_ru

написал вопрос - написал ответ который думаешь (буквами а не заставляй рассматривать скриншетик)

написал почему так думаешь

это ж у тебя бомбит)

блин как грустно

вот вот самое подходящее - грустно

нет, понятно что можно объявить) ... но мы же "хотим" нарушить LSP ... был интерфейс, мы сделали реализацию, в которой нарушили контракт ... с точки зрения языка всё ок ... статический анализатор не помог

нам даже не надо искллючение для этого) там дофига вариантов когда язык пропустит, но принцип нарушится

инварианты чаще можно только в рантайме проверить

и тут статический анализ проигрывает тестам

а вообще - это ж все чисто основы логики

Не зависим от того что нам не нужно

нам даже не надо искллючение для этого) там дофига вариантов когда язык пропустит, но принцип нарушится

Вот и я согласен на 100% с этим

Не зависим от того что нам не нужно

Any objections?

https://i.imgflip.com/24mlqr.jpg

интересно нашли ли тут люди тонкую отсылку на LSP

https://i.imgflip.com/24mlqr.jpg

лол.

я тут коллеге недавно накидывал пример нарушения и не нарушения LSP, а то он долго вкурить не мог, а теперь прям интересно стало, я сам не накосячил-ли. а то человек поверил. https://gist.github.com/telless/657df088cdf3eff026a5247c85cc8481

я тут коллеге недавно накидывал пример нарушения и не нарушения LSP, а то он долго вкурить не мог, а теперь прям интересно стало, я сам не накосячил-ли. а то человек поверил. https://gist.github.com/telless/657df088cdf3eff026a5247c85cc8481

ток оно для плохого примера упадет по причине несоответствия сигнатур

ток оно для плохого примера упадет по причине несоответствия сигнатур

только по возврату, входящие работают, но ворнингом кидаются

Да это как раз инетрпретатор ругнется

но я намеренно показывал "все плохие варианты"

только по возврату, входящие работают, но ворнингом кидаются

ну так ворнинг

но все верно

ну то есть bad нарушает, good не нарушает

но нарушение только на уровне аргумента второго обязательного

но нарушение только на уровне аргумента второго обязательного

а использование FooChild вместо Foo разве не нарушение во входящих параметрах?