> Читабельность хуже меньше читать (имплементации) = читабельность хуже? Каким образом? >

код менее явный

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

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

Не унаследовать, а РЕАЛИЗОВАТЬ. Вообще срать на дефолтную реализацию - от нее ничего не зависит, ее НЕ нужно использовать в твоей собственной реализации и никакой код от нее не зависит. Это все еще интерфейс. Не антипаттерн.

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

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

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

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

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

В интерфейсы? Я хз, я такого не видел. С джавой я на работе не работаю. А вот в ПХП повидал кучу трейтов с хелпер методами. Это не значит, что поэтому трейты гавно (они гавно, но не по этой причине), а только то, что есть криворукие разработчики.

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

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

По сути, вынося этот метод в интерфейс-маркер или просто отдельный наследованный интерфейс, ты переносишь логику определения того, является ли правило implicit'ом, из правила в отдельное место, ведь каждый раз, что бы это проверить, тебе нужно делать ($rule instanceof ImplicitableRule && $rule->isImplicit()), а это уже кандидат на то, что бы оставить это каким-то отдельным методом в каком-то классе, дабы не дублировать эту логику. Если бы дополнительного интерфейса не было, то и ->isImplicit() можно было бы вызывать сразу и доп. обертка не нужна.

Пример exaggerated, конечно. Есть и другие кейсы. Если хочешь, могу еще примеров накидать, поискать в опен-сорс проектах.

> меньше читать (имплементации) = читабельность хуже? Каким образом? Тем образом, что 10% пользователей будут переопределять метод и ставить true, а значит в каждом классе среди десятков других методов нужно искать этот метод и смотреть его реализацию (true там или false) + ещё и писать этот метод (буковок больше, чем с интерфейсом-маркером в начале файла) > не важно. Если код написан нормально, то излишняя явность не к месту. Она не излишняя. Она необходима для понимания как код работает (в твоём случае с implicit или без). Иначе возможны человеческие ошибки. > Не унаследовать, а РЕАЛИЗОВАТЬ. Именно унаследовать, т.к. базовая реализация уже есть. А ещё не забывай о возможности интерфейса наследовать другой интерфейс + можешь загуглить java default method inheritance или посмотреть раздел 9.4.1 спецификации джавы. > Вообще срать на дефолтную реализацию - от нее ничего не зависит Меня учили, что в таких случаях "оно не нужно". А если оно не нужно, то в контракте не нужно тем более. > ее НЕ нужно использовать в твоей собственной реализации и никакой код от нее не зависит Какого хрена это говно в контракте, если его не должно быть в реализации (классе и инстансах класса) и никакой код от него не зависит? > Не антипаттерн. Антипаттерном будет когда те самые 10% (или меньше) начнут изменять поведение метода с дефолтной реализацией. > Если ты изменяешь контракт, то делаешь это так, что бы его поведение соответствовало поведению до твоих изменений В некоторых случаях это невозможно (если меняется поведение, а сигнатуры по типам и названиям методов не отличаются). С дефолтными реализациями это ещё более усугубляется (проблемы могу быть довольно разные, но можешь представить себе переименование метода с дефолтной реализацией, который уже отнаследовали и сменили false на true). Если раньше нужно было следить за N опасных моментов, то с деф. реализациями — за N+M. > Это не проблема юзера интерфейса, а разработчика, пишущего интерфейс. Не буду писать сколько из них забивают, а сколько из них не знают или не понимают. Как после этого можно назвать подход "простым"? > Равно как и не мешает использовать вместе с наследованием Я уже писал, что мешает. Мешает невозможность отказа от ненужных методов, добавленных в класс и инстансы класса через дефолтные методы интерфейсов. > В интерфейсы? Я хз, я такого не видел. С джавой я на работе не работаю. А вот в ПХП повидал кучу трейтов с хелпер методами. В трейтах этот момент уже не говно, я уже писал. Почему в трейтах не говно? Потому что от трейта ты можешь отказаться, а от деф. методов в интерфейсе — нет. > Не-а, ведь нужно принять аргумент на вход - RuleValidationContext, значит должен быть метод Всё так же можно обойтись маркером без добавления ненужных методов. > ты переносишь логику определения того, является ли правило implicit'ом, из правила в отдельное место, ведь каждый раз, что бы это проверить, тебе нужно делать ($rule instanceof ImplicitableRule && $rule->isImplicit()) А вот и нихера. Абсолютно нихера. В том месте, где у тебя был $rule->isImplicit() будет $rule instanceof ImplicitRule, а у 90% правил будет всё так же, как и ранее. Остальные 10% правил вместо метода isImplicit() { return true } получат более простой для чтения implements ImplicitRule в начале класса.