или заимплементил интерфейс?

с точки зрения пользователя кода

который потом тайпхинты ставит

он ожидает определенного поведения от интерфейса

интерфейс декларирует тебе только то что у тебя есть метод. а то какая реализация может быть для него - это уже не его проблемы

вон пример выше с кешем. для void кеша ты можешь дого ожидать что тебе после set что-то вернет get

это проблемы пользователя

ему это важно

ну так и doublelist тоже проблемы пользователя. семантика ведь не нарушена

да, но lsp нарушен

почему? класс просто расширен

он не меняет поведение базового

я про double

потому что пользователи интерфейса не могут безболезненно переключиться с одной реализации на другую

сломан контракт

и весь интерфейс потерял смысл

если я не могу подменить реализацию, то зачем мне какая-то абстракция между мной и реализацией?)

возвращаемся к кешу с самыми разными подтипами

давай

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

но это уже его проблемы что он там ожидает

интерфейс соблюден же

вот сейчас ничего не понял

покажи мне интерфейс и контракт

если я не могу подменить реализацию, то зачем мне какая-то абстракция между мной и реализацией?)

что тебе мешает подменить List на DoubleList? код скомпилируется, работать будет

что тебе мешает подменить List на DoubleList? код скомпилируется, работать будет

while (list.length < 5) { list.add(this.nextSomeNeededThingForList()); }

покажи мне интерфейс и контракт

видимо он имеет в виду, что реализация соответствует интерфейсу, но результат из кэша необзятаельно может вернуться сразу (в зависимости от реализации). ну это очевидный момент

покажи мне интерфейс и контракт

<?php interface Cache { public function set($name, $value); public function get($name); } class ArrayCache implements Cache { private $state = []; public function set($name, $value) { $this->state[$name] = $value; } public function get($name) { return $this->state[$name] ?? null; } } class VoidCache implements Cache { public function set($name, $value) { } public function get($name) { return null; } }

ну окей

банальный nullobject

и ты везде опираешься на интерфейс и можешь заменить реализацию на любой его подтип

окей, нам теперь надо выделить контракт

грубо говоря как связаны set и get?

если никак, то отлично, обе реализации соответствуют этому

и пользователь кода этого ожидает от поступающих реализаций

а если он будет думать, что после set обязательно должно это значение отдаться по get, то такой код сломается

окей, нам теперь надо выделить контракт

интерфейс выступает в роли контракта и явно не описывает то как связаны get/set

это не всегда так

в интерфейсе мы не можем описать связи, мы их описываем где-то еще

тесты\просто по использованию интерфейса

у тебя тесты будут на конкретные реализации

нет

тесты будут на взаимодействие моего кода с интерфейсом

у тебя тесты будут на конкретные реализации

чёрный ящик это тест на интерфейс

интерфейсом владеет пользователь, а не реализация

поэтому интерфейс в первую очередь это его ожидания

тесты будут на взаимодействие моего кода с интерфейсом

интерфейс тебе явно не опишет все. поэтому ожидания пользователя не всегда есть правдивые

ну вот про это LSP и говорит

что мы можем вроде бы все методы заимплементить

но как-то не так

вот remove у нас будет добавлять

а add искать

а has добавлять

и вот что-то потом пойдет не так)

при этом код конечно же скомпилируется

семантически все будет верно)

ERROR: S client not available

if (!list.has(item)) list.add(item);

)

это особенно хорошо понятно, когда проектируешь сверху вниз

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

ага, какой-нибудь Notificator, пускай с методом notify

ага, Catalog с методами... И т.д. А если там ничего нет, то должен быть такой-то Exception

и только потом ты идешь реализовывать эти интерфейсы, но ты реализуешь их оглядываясь на то, чего ты ждал, когда делал предыдущий модуль

т.е. там, где они нужны

недосып) либо к паренту либо переделывать

Всем привет. Собрал в одном месте все чаты для программистов - @Chats_Developers, пользуйтесь на здоровье. Ваш чат у нас тоже есть, не удаляйте это сообщение.

if (!list.has(item)) list.add(item);

Вот только абстракция дырявая

Чуть усложним: пусть тут не список, а множество. Какие требования к item предъявишь?

Вот только абстракция дырявая

?

Чуть усложним: пусть тут не список, а множество. Какие требования к item предъявишь?

Я редко занимаюсь проектированием абстрактных математических сущностей. Какие надо, такие и предъявлю. Там есть условие уникальности?

Тогда item должен обладать свойством сравнимости или типа того

Разумеется, если множество на деревьях, то достаточно, чтобы был частичный порядок на множестве item, а если на хешмапах, то должно быть определена эквивалентности и хешируемость. А если на массиве, то просто эквивалентность

Так, ну окей

При этом абстрактный тип остается один --- множество

Вот только абстракция дырявая

Получаем это

При этом абстрактный тип остается один --- множество

Почему?

Мы не можем один Set другим подменить

Точнее только более частный более общим

Про это lsp и говорит

Ну либо я тебя не понял

Почему?

Потому что множество не завязано на реализацию, в математике никакой хешируемости и порядка не надо

А причем здесь математика?

Про это lsp и говорит

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