> Да, именно так и есть. Читай пример ниже с

валидацией.

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

> Дефолтная реализация - не унаследованный метод

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

> О каком контроле и безопасности идет речь?

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

> Композиция = минус наследование

Вот тут и дальше в абзаце какой-то булшит откровенный. Ничто не мешает использовать композицию вместе с трейтами, если тому есть необходимость.

> Весь котлин на этом построен, а мне он очень нравится

Правильно. Зачем логика, если есть "модные словечки" (ещё бы смысл понимать) и обаяние языка.

> Че? В смысле "не требуются"? Если добавляют в контракт, то значит в некоторых кейсах они нужны

Комменты пиши, изначальный тред не читай, ага. Перечитай то, что я писал в самом начале. Именно "не требуются", да. Люди добавляют деф. реализацию методов в контракт даже когда эти методы не требуются. Именно! Для чего? "А вдруг кому-то нужен будет вот этот красивенький метод, без которого 100% не обойтись, ведь я же его написал". Нахера ISP? Нахера в контрактах только то, без чего другой код не будет работать? Ведь хелперы нужны всем!

> Там контракты нахер не сдались.

Если там контракты не сдались, то почему ненужные методы именно в интерфейсы заталкивают, га?

> ISP это ...? И с чего ты взял, что там обязательно будет куча говна?

Сергей уже ответил выше. Если принцип нарушается, то нередко может получиться говно (ведь совершенно разное подаётся под одним "соусом").

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

Я бы сказал добавить отдельный интерфейс-маркер для подобных банальных булевых хренотеней. И не будет захламлений классов ненужными методами, в отличии от твоего варианта. А проверка по instanceof ничем не хуже проверки запуском метода контракта (в котором ещё и ошибку допустить могут).

> Читабельность хуже меньше читать (имплементации) = читабельность хуже? Каким образом? > код менее явный не важно. Если код написан нормально, то излишняя явность не к месту. > Вот только что бы изменить его, тебе нужно будет его унаследовать и написать тело метода. И если поведение будет отличаться, то ты делаешь как велит антипаттерн. И вся эта херня с деф. реализациями и поощряет писать этот антипаттерн. Не унаследовать, а РЕАЛИЗОВАТЬ. Вообще срать на дефолтную реализацию - от нее ничего не зависит, ее НЕ нужно использовать в твоей собственной реализации и никакой код от нее не зависит. Это все еще интерфейс. Не антипаттерн. > О том контроле, что любое изменение контракта должно быть явным, иначе с деф. реализациями есть шанс проебать одно из изменений, а чекер не подскажет ошибки из-за того, что контракт выполняется (метод же реализован в деф. реализации). В итоге ошибки с потолка, когда можно было обезопаситься заранее. Если ты изменяешь контракт, то делаешь это так, что бы его поведение соответствовало поведению до твоих изменений. Это не проблема юзера интерфейса, а разработчика, пишущего интерфейс. > Вот тут и дальше в абзаце какой-то булшит откровенный. Ничто не мешает использовать композицию вместе с трейтами, если тому есть необходимость. Равно как и не мешает использовать вместе с наследованием. Дальше что? Трейты - не композиция. Более того, у трейтов все те же минусы, что и у наследования, кроме отсутствия возможности "наследоваться" от нескольких классов (трейтов). Не буду расписывать в чем преимущество композиции, разговор же не об этом. > Если там контракты не сдались, то почему ненужные методы именно в интерфейсы заталкивают, га? В интерфейсы? Я хз, я такого не видел. С джавой я на работе не работаю. А вот в ПХП повидал кучу трейтов с хелпер методами. Это не значит, что поэтому трейты гавно (они гавно, но не по этой причине), а только то, что есть криворукие разработчики. > интерфейс-маркер Не-а, ведь нужно принять аргумент на вход - RuleValidationContext, значит должен быть метод. А значит это уже не интерфейс-маркер, а расширенный интерфейс Rule, как я и говорил. Неа, это костыль. > А проверка по instanceof ничем не хуже проверки запуском метода контракта (в котором ещё и ошибку допустить могут). Ты и так запускаешь метод, только теперь еще и с доп проверкой до. По сути, вынося этот метод в интерфейс-маркер или просто отдельный наследованный интерфейс, ты переносишь логику определения того, является ли правило implicit'ом, из правила в отдельное место, ведь каждый раз, что бы это проверить, тебе нужно делать ($rule instanceof ImplicitableRule && $rule->isImplicit()), а это уже кандидат на то, что бы оставить это каким-то отдельным методом в каком-то классе, дабы не дублировать эту логику. Если бы дополнительного интерфейса не было, то и ->isImplicit() можно было бы вызывать сразу и доп. обертка не нужна. Пример exaggerated, конечно. Есть и другие кейсы. Если хочешь, могу еще примеров накидать, поискать в опен-сорс проектах.