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

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

а, и конечно решается проблема “если плохой разработчик видит публичный метод, он его юзает” (с)

есть что еще полезного в ISP?

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

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

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

Ну вот у тебя один класс с этим интерфейсом, второй, а третий уже не нуждается во всех методах жирного интерфейса, а только в части

В принципе, когда возникает такая ситуация тебе и придется заюзать isp и выделять интерфейсы

Годится, реюз интерфейсов. Хотя и к isp имхо только косвенно относится. По определению, речь идёт о клиентском коде, что мы не должны заставлять клиента зависеть от большего, чем ему нужно

Клиентский код на это может писать кто угодно: ты сам, твои коллеги, ты через год, юзеры твоей либы... вариантов масса. И хорошо если ты сам и сможешь отрефакторить потом

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

"интерфейс" (существует он явно как сущность языка или просто публичный интерфейс класса) определяет контракт. Isp тебе говорит что проектировать контракт стоит на основе поведения которое требует клиентский код

Жирные интерфейсы общего назначения имеют тенденцию чаще меняться

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

Дальше начинаются нюансы языков. Для пыхи работают все примеры из джавы. В то время как другие языки решают часть проблем по-другому (делегаты в котлине, структурный тайпинг в го)

Смысл все равно в том что бы менее стабильные модули зависили от более стабильных

За счёт этого мы уменьшаем риски каскада изменений

я повторю мысль - не стоит смотреть на солид в вакууме. Для использования этих принципов надо разбираться "почему код меняется". Цель - уменьшение рисков изменений кода (потому например важен open/close). Еще можно на это все смотреть через призму "маленькие одноразовые объекты". Мол сделал маленький контракт узко специализированный и в следующий раз вместо того что бы менять его - завести новый и выкинуть старый. Это дает больше контроля над рисками

Пример тому - 2 psr про кэш