до тех пор пока ты соблюдаешь LSP - все хорошо

ну кстати да

в твоем случае если у тебя наследник усилил пост-условия (о том что он не всякий Product будет возвращать а только Book, который является подтипом Product), то с точки зрения LSP все хорошо.

так а где плохо?

когда ты усиливаешь пред-условия. Типа у тебя интерфейс на ВХОД принимал Product и в наследнике ты хочешь не просто Product а Book. Вот в этом случае LSP нарушен.

это понимаю

предусловия не сильнее

постусловия не слабее

ну тип того, но... увы PHP не умеет ковариантность типов, а стало быть ты физически ограничен. Где-то была RFC что бы это разрешить но хз как оно там

сча попробуй найти

самому интересно

а не.... нету. Было просто мельком в internals и как-то заглохло.

Но, в 7.2 можно будет хотя бы убирать типы в наследниках для входа (ослоблять прекондишены)

https://wiki.php.net/rfc/parameter-no-type-variance

это конечно не то что надо, но...

в принципе

разницы нет, book там или product

может замутить RFC...

по сути book все равно реализует product

ERROR: S client not available

Сергей наверное знает какие подводные камни есть

Ну, когда ты знаешь, что там именно book, надо делать лишнюю проверку

по сути book все равно реализует product

на это надо смотреть исходя из задачи. К примеру: $book = $bookFactory->make('War and Peace'); // $book instanceof Book $food = $foodFactory->make('Fish and Chips'); // $food instanceof Food class Book implements Product, Readable; class Food implements Product, Eatable;

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

и ему очень важно что бы фабрика вернула именно Book.

то есть в качестве зависимости у нее будет не просто ProductFactoryInterface а скорее BookFactory

пример немного высосан из пальца, лень придумывать что-то из реальной жизни.

но идея тут именно в ISP, то есть смотреть надо не только на сами типы, но то кто и зачем их хочет использовать