а интерфейс, значит, мы запретили менять каким-то волевым решением?

а интерфейс, значит, мы запретили менять каким-то волевым решением?

Не запретим. но наш скласс реализующий этот интерфейс скажет нам об этом если интерфейс поменяется

а интерфейс, значит, мы запретили менять каким-то волевым решением?

Типа абстрактный класс

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

то есть если покалечить некий класс не запрещено, то почему пользоваться этим классом нормально, а наследоваться от него ненормально?

чем наследование от класса хуже использования?

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

Ну не только покалечить. он может просто что-то изменить и пофиксить багу. а мы от этого метода зависим в дочернем классе

а если от этого метода зависит что-то еще в проекте?

ну вот на конкретном примере, раньше метод возвращал boolean, а начал возвращать массив

Все поломается. и мы узнаем поздно. А интерфейс с бережет от этого

ну вот на конкретном примере, раньше метод возвращал boolean, а начал возвращать массив

Типизирование нужно

ну вот на конкретном примере, раньше метод возвращал boolean, а начал возвращать массив

интерфейс не допустит этого как минимум. если допустит мы до компилятора еще узнаем о этом

ну какие компиляторы в интерпретируемом языке? :)

все равно как-то странно получается

объявляем интерфейс, в котором заявляем, что метод возвращает boolean

ну какие компиляторы в интерпретируемом языке? :)

Окей. до вывода в продакшен.

создаем класс, который реализует интерфейс

окей

Окей. до вывода в продакшен.

в тест. пофиг

если балбес в классе поменял возвращаемый тип, получил ошибку

что мешает балбесу изменить интерфейс?

ничего. но мы это поймем в своем классе

Что мешает балбесу случайно удалить весь проект

у нас тоже реализует интерфейс класс

а у нас класс сломается...

ну вообще да

только для этого интерфейс необязателен

Что мешает балбесу уронить стойку с сервером

а у нас класс сломается...

Так мы это поймем. а при наследовании нет.

а если мы хинт приделаем к этому классу?

что метод возвращает конкретный тип

неужели у нас интерпретатор не ругнется, что мы его теперь переопределяем?

а толку ? я в родительском могу его изменить

Интерфейс еще нужен для принципа подстановки solid. И чтобы можно было адаптеры прикручивать

не для солид. а для контейнера

я ж не против интерфейсов

просто не понимаю этой панической боязни наследования

вроде смысл претензии прояснился

но...

> Что мешает балбесу уронить стойку с сервером

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

Я не говорил что это панические болезни. Я наследуюсь когда это нужно. Просто иногда это не нужно. А тут всегда советуют "наследование" даже когда этого вообще не нужно

ну да yii2 не всегда дает хорошие интсрументы для правильной архитектуры. и с этим ничего нельзя сделать

кстати только что проверил

просто не понимаю этой панической боязни наследования

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

The enforcement of the declared return type during inheritance is invariant; this means that when a sub-type overrides a parent method then the return type of the child must exactly match the parent and may not be omitted. If the parent does not declare a return type then the child is allowed to declare one.

если в родительском классе указан возвращаемый тип, то в наследниках придется указывать такой же

в php7

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

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

просто не понимаю этой панической боязни наследования

Тут не боязнь. Просто если знаешь минусы и плюсы наследования то пересматриваешь архитектуру и сам свой код, не более того

не для солид. а для контейнера

Для инверсии зависимости

Для инверсии зависимости

и ?

И всн

Тут не боязнь. Просто если знаешь минусы и плюсы наследования то пересматриваешь архитектуру и сам свой код, не более того

https://youtu.be/G6LJkWwZGuc?t=9m49s вот кстати чувак говорит почему наследование плохо.

И всн

как раз контейнер и это реализует

Даже кто-то умный говорил, мол предпочитайте композицию наследованию

как раз контейнер и это реализует

Ты про di контейнер?

да.

Даже кто-то умный говорил, мол предпочитайте композицию наследованию

все так говорят, потому что попаболи меньше

когда domain expert приходит и говорит теперь нам нужно так, а не эдак

а хотелки бизнеса имеют свойство плодиться, а когда архитектура завянана на наследование это сильная связность, гуглить в сторону coupling && cohesion

и почему это плохо

идеальная грань посередине, что собственно нам и дает композиция

Но насколько я понимаю, правильный декоратор тот, который реализует интерфейс декорируемого объекта

В юи с этим сложно

ERROR: S client not available

Особенно для эктив рекорд моделей

В ddd еще норм

вот реквестирую @yegor256 с докладом о том, почему AR анти паттерн

но это считай необходимое зло

потому что мы так привыкли делать

Увы, юи его использует

Поэтому декоратор приходится делать без реализации интерфейса

Ибо это боль, все методы реализовывать и делегировать внутреннему объекту

В юи с этим сложно

Можно спокойно.

Можно магическими методами как поведения прокидывать

не один yii, сути вещей не меняет, можно на вещи смотреть по разному и задача разработчика выбрать путь которые в перспективе будет менее болезненный в поддержке напиливанию новых фич и тд, потому и приходится идти на своего рода компромисы, потому и inheritance is evil

Можно спокойно.

Чтоб сделать декоратор ар модели ты все функции реализуешь из интерфейса?)

аа AR. у меня еще перед AR абстракция

Поэтому в контексте ар моделей это боль юзать правильную декорацию

хм. для чего тут нужна декорация в AR ?

не могу придумать кейс

Чтобы добавить доп функциональность динамически

Для чего и служат декораторы

Сталкивался с этим давно, но забил

я знаю для чего обычно они служат. Ну у меня это делают отдельные классы.

и не декораторы

Ну рад за вас

)))

Тут ведь вопрос архитектуры

Выдохся холивар

его не было

Читаю про DDD на сон грядущий :) Может есть у кого ещё примеры DDD на базе AR и Yii2, кроме Дмитрия Елисеева (https://github.com/ElisDN/yii2-demo-aggregates/tree/ar) ?

[['password'], 'string', 'min'=>6, 'message'=>'Минимальная длинна пароля 6 символов'],

Вывод message не работает. Как записать правильно?

Не работает потому что на длину может быть не message а например messageLenght

tooShort вместо message http://stuff.cebe.cc/yii2docs-ru/yii-validators-stringvalidator.html#$tooShort-detail

configuring node js support