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

что 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 в начале класса.

> Тем образом, что 10% пользователей будут переопределять метод и ставить true, а значит в каждом классе среди десятков других методов нужно искать этот метод и смотреть его реализацию (true там или false) + ещё и писать этот метод (буковок больше, чем с интерфейсом-маркером в начале файла) > Всё так же можно обойтись маркером без добавления ненужных методов. > А вот и нихера. Абсолютно нихера. В том месте, где у тебя был $rule->isImplicit() будет $rule instanceof ImplicitRule, а у 90% правил будет всё так же, как и ранее. Остальные 10% правил вместо метода isImplicit() { return true } получат более простой для чтения implements ImplicitRule в начале класса. Ты упустил, что я сказал. Сигнатура такая: public function isImplicit(RuleValidationContext $context): bool а не такая public function isImplicit(): bool поэтому интерфейсом-маркером тут не обойтись. > Она не излишняя. Она необходима для понимания как код работает (в твоём случае с implicit или без). Иначе возможны человеческие ошибки. Нет, именно излишняя. Ты, как разработчик на проекте, знаешь, что дефолтное значение фолс (потому что заглядывал), или вообще не знаешь о существовании метода, так как тебе это не интересно. Ситуации, когда ты бы знал, что существует метод isImplicit (иначе зачем тебе его искать?), но не знал, какое у него дефолтное значение, да еще и было бы лень заглянуть в интерфейс одним кликом - не бывает. > Именно унаследовать, т.к. базовая реализация уже есть. Ну как блять унаследовать, если никто не заставляет тебя использовать ту реализацию? Унаследуешь ты, если ты обязан вызвать parent, а тут ты не то что не обязан, а вообще не можешь этого сделать физически. Да и как бы ты это не называл, МИНУСОВ наследования (в привычном нам смысле) у дефолтных имплементаций нет и быть не может. > Меня учили, что в таких случаях "оно не нужно". А если оно не нужно, то в контракте не нужно тем более. Хз что на это ответить. Это вообще не аргумент) Меня многому учили, но я понял, что ебал я ваши бест практисы и крутые термины, если я сам не понимаю, нахрен оно нужно. В первую очередь нужно самому думать, во вторую - доверять проверенным публичным группам людей) > Какого хрена это говно в контракте, если его не должно быть в реализации (классе и инстансах класса) и никакой код от него не зависит? В смысле не должно? Оно есть в контракте. Это ЧАСТЬ контракта. Все, что делает дефолтная реализация - избавляет от бойлерплейта во всех реализациях, но это не значит, что это не является частью контракта. И что значит "никакой код от него не зависит"?) Это на то и ДЕФОЛТНАЯ реализация, а не просто реализация - ты либо оставляешь как есть, либо ПЕРЕОПРЕДЕЛЯЕШЬ, но никак не расширяешь функционал. Это ШАБЛОН для удобности программиста. > Антипаттерном будет когда те самые 10% (или меньше) начнут изменять поведение метода с дефолтной реализацией. Не будет. Еще раз: переопределение является антипаттерном только в контексте наследования, потому что такой код невозможно юнит тестировать. Нельзя замокать перент метод и, соответственно, нельзя нормально, без повторений, протестить унаследованный. В данном случае это НЕПРИМЕНИМО, так как ни к какому перенту никто и никогда не стучится. У тебя есть дефолтная реализация, которую ты тестируешь, и отдельно ты тестируешь имплементации, но тесты нигде не повторяются (так как реализации метода не повторяются и не переиспользуют перент реализацию) и, следовательно, это НЕ есть антипаттерн. > В некоторых случаях это невозможно (если меняется поведение, а сигнатуры по типам и названиям методов не отличаются) Тогда ты обязан сделать другой интерфейс. Опять же, ничего общего с дефолтными методами. Ты так же мог сменить назначение других методов без дефолтной реализации без предупреждения. > Если раньше нужно было следить за N опасных моментов, то с деф. реализациями — за N+M.

Кол-во такое же. Как было N методов, так и осталось N методов. Вообще такие ситуации - это нонсенс. Разработчики библиотек обязаны писать об этом в апгрейд гайд и менять название/неймспейс интерфейса, а пользователи - читать гайд и адаптироваться под изменения. > Не буду писать сколько из них забивают, а сколько из них не знают или не понимают. Как после этого можно назвать подход "простым"? Меняя название/неймспейс, ты почти гарантируешь то, что никто не проебеться. Так или иначе, я не собираюсь говорить, что фича говно, только потому что есть 0.001% дебилов, не понимающих, что нужно смотреть в апгрейд гайд когда апгрейдишь мажорные версии зависимостей. > Я уже писал, что мешает. Мешает невозможность отказа от ненужных методов, добавленных в класс и инстансы класса через дефолтные методы интерфейсов. што? Еще раз: я сказал, что композицию МОЖНО использовать вместе с наследованием. Причем тут интерфейсы? Да и даже говоря об интерфейсах, я уже говорил, что это не "ненужные методы", а часть контракта. > В трейтах этот момент уже не говно, я уже писал. Почему в трейтах не говно? Потому что от трейта ты можешь отказаться, а от деф. методов в интерфейсе — нет. Не используй гавно-интерфейс? Не пиши гавно-интерфейс? Не понимаю, в чем проблема. Ты что, считаешь что можно физически ограничить разработчиков от написания гавно-кода? Нельзя. Можно минимизировать риски проеба мидла+ за счет фич типа типизации и написания тестов, но если какой-то мудак захочет написать говно, то его удержит только ревью его пулл реквеста в мастер. Гавно можно написать не только с помощью дефолтных реализаций.