> Как будто с дефолтной реализацией читабельность, простота и поддержка

выше, чем без неё. Как я писал — как раз таки наоборот.

Да, именно так и есть. Читай пример ниже с валидацией.

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

што? Дефолтная реализация - не унаследованный метод, а метод интерфейса. Ты все так же можешь использовать композицию и вообще делать с этим методом все тоже, что и с методом интерфейса, у которого нет дефолтной реализации. Разницы никакой от слова "совсем".

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

О каком контроле и безопасности идет речь? Если ты не используешь статику, то все будет в порядке, так как максимум, что ты можешь сделать в дефолтной имплементации - вернуть дефолтное примитивное значение или вызвать оверлоаднутый метод.

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

> Шта?

Композиция = минус наследование. А трейты - как раз аналог наследования, ибо стучишься ты к $this или self. Никакого тебе юнит тестирования, ибо подменить реализацию ты не можешь, да и самой по себе композиции тут так же не выйдет.

> Последователи DRY-секты в треде?

Весь котлин на этом построен, а мне он очень нравится. Нравится то, что там только экстракт кода и ничего лишнего.

> Нет, речь не об этом. Речь об добавлении нового класса, который реализует методы, которые не требуются в контракте (а именно так оно и есть с интерфейсами и деф. реализацией всяких utils/helpers, мало кому нужных).

Че? В смысле "не требуются"? Если добавляют в контракт, то значит в некоторых кейсах они нужны, просто не всегда. Причем тут вообще utils/helpers? Там контракты нахер не сдались.

> Речь была о другом, но отвечу... Правильно. Лучше нарушать ISP, объеденив кучи говна в одном месте.

ISP это ...? И с чего ты взял, что там обязательно будет куча говна? Давай конкретный пример:

ты пишешь валидатор и у тебя есть контракт Rule. У него есть метод validate(RuleValidationContext $context): void, отвечающий, собственно, за валидацию, и isImplicit(RuleValidationContext $context): bool, отвечающий за то, запускать ли правило валидации, если валидируемое значение - null.

При том 90% правил, которые пишут пользователи, не implicit, так что логично дефолтным значением сделать false.

Вынеси в отдельный интерфейс, скажешь ты... и в итоге получим интерфейс ImplicitableRule extends Rule, у которого будет тупо добавлен тот же метод, а потом еще и проверки на instanceof вместо того, что бы просто дернуть метод.

При том этот метод является частью правила, а ImplicitableRule - это просто расширенный обычный Rule.

ImplicitableRule тут - как раз и есть костыль, существующий только для того, что бы решить несуществование дефолтной реализации. Больше в нем нет никакого смысла от слова "совсем".

ISP - Interface Segregation Principle - самый недооцененный принцип из SOLID :) и самый простой

> Да, именно так и есть. Читай пример ниже с валидацией. Прочитал. Читабельность хуже, код менее явный. Как я и предполагал. Должен быть отдельный контракт (или контракт-маркер). > Дефолтная реализация - не унаследованный метод Вот только что бы изменить его, тебе нужно будет его унаследовать и написать тело метода. И если поведение будет отличаться, то ты делаешь как велит антипаттерн. И вся эта херня с деф. реализациями и поощряет писать этот антипаттерн. > О каком контроле и безопасности идет речь? О том контроле, что любое изменение контракта должно быть явным, иначе с деф. реализациями есть шанс проебать одно из изменений, а чекер не подскажет ошибки из-за того, что контракт выполняется (метод же реализован в деф. реализации). В итоге ошибки с потолка, когда можно было обезопаситься заранее. > Композиция = минус наследование Вот тут и дальше в абзаце какой-то булшит откровенный. Ничто не мешает использовать композицию вместе с трейтами, если тому есть необходимость. > Весь котлин на этом построен, а мне он очень нравится Правильно. Зачем логика, если есть "модные словечки" (ещё бы смысл понимать) и обаяние языка. > Че? В смысле "не требуются"? Если добавляют в контракт, то значит в некоторых кейсах они нужны Комменты пиши, изначальный тред не читай, ага. Перечитай то, что я писал в самом начале. Именно "не требуются", да. Люди добавляют деф. реализацию методов в контракт даже когда эти методы не требуются. Именно! Для чего? "А вдруг кому-то нужен будет вот этот красивенький метод, без которого 100% не обойтись, ведь я же его написал". Нахера ISP? Нахера в контрактах только то, без чего другой код не будет работать? Ведь хелперы нужны всем! > Там контракты нахер не сдались. Если там контракты не сдались, то почему ненужные методы именно в интерфейсы заталкивают, га? > ISP это ...? И с чего ты взял, что там обязательно будет куча говна? Сергей уже ответил выше. Если принцип нарушается, то нередко может получиться говно (ведь совершенно разное подаётся под одним "соусом"). > Вынеси в отдельный интерфейс, скажешь ты... и в итоге получим интерфейс ImplicitableRule extends Rule, у которого будет тупо добавлен тот же метод, а потом еще и проверки на instanceof вместо того, что бы просто дернуть метод. Я бы сказал добавить отдельный интерфейс-маркер для подобных банальных булевых хренотеней. И не будет захламлений классов ненужными методами, в отличии от твоего варианта. А проверка по instanceof ничем не хуже проверки запуском метода контракта (в котором ещё и ошибку допустить могут).