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

читабельность, простота и поддержка выше, чем без неё. Как я писал — как раз таки наоборот. К тому же деф. реализация ещё и подталкивает юзать один из антипаттернов, смысл которого заключается в изменении поведения унаследованного метода.

> Все указанные варианты - либо сложнее, либо дольше

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

> они идут вразрез з композицией

Шта?

> Копипаст - бредятина. Чем меньше кода (без ущерба качеству) - тем лучше. Я всегда против лишней вербозности или лишних конструкций

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

> Если речь о том, что бы вместо добавления метода в существующий интерфейс

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

> Зачем разработчику юзеру-интерфейсов помнить (или искать) названия других интерфейсов?

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

> Как будто с дефолтной реализацией читабельность, простота и поддержка выше, чем без неё. Как я писал — как раз таки наоборот. Да, именно так и есть. Читай пример ниже с валидацией. > подталкивает юзать один из антипаттернов, смысл которого заключается в изменении поведения унаследованного метода. што? Дефолтная реализация - не унаследованный метод, а метод интерфейса. Ты все так же можешь использовать композицию и вообще делать с этим методом все тоже, что и с методом интерфейса, у которого нет дефолтной реализации. Разницы никакой от слова "совсем". > Ну да, конечно, композиция и трейты сложнее дефолтной реализации. И дольше, ага... А о контроле и безопасности мы забываем. На них наплевать и это ни разу не важно. О каком контроле и безопасности идет речь? Если ты не используешь статику, то все будет в порядке, так как максимум, что ты можешь сделать в дефолтной имплементации - вернуть дефолтное примитивное значение или вызвать оверлоаднутый метод. А какую-то сложную бизнес логику невозможно выстроить без кучи зависимостей, доступа к которым у тебя там не будет. > Шта? Композиция = минус наследование. А трейты - как раз аналог наследования, ибо стучишься ты к $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 тут - как раз и есть костыль, существующий только для того, что бы решить несуществование дефолтной реализации. Больше в нем нет никакого смысла от слова "совсем".