A
Сложно это представить. Как абстрактный класс?
Можно сказать и так. Только мы не можем отнаследоватся от нескольких абстрактных классов. А использовать несколько интерфейсов/трейтов можем.
Size: a a a
2020 May 28
M
Можно сказать и так. Только мы не можем отнаследоватся от нескольких абстрактных классов. А использовать несколько интерфейсов/трейтов можем.
По идее трейты и придуманы для множественного наследования
MM
По идее трейты и придуманы для множественного наследования
Давно?)
A
По идее трейты и придуманы для множественного наследования
Мне вообще пофиг, зачем их придумывали в пхп. Я лишь сказал, где, по-моему, их оправдано использовать.
M
Давно?)
Давно )
MM
Ясна
ВУ
Оригинальный не нашел, поэтому написал по памяти. Если ошибся в реализации оригинальной идеи, пусть автор простит
https://pastebin.com/wCaZbA6j
https://pastebin.com/wCaZbA6j
я не скрываю, у меня есть такой PR в messenger: https://github.com/symfony/symfony/pull/34310/files#diff-83948907a24dc6a7916f694811a00ce1R19
и на тот момент я считал, что трейт в библиотеке для примера реализации интерфейса — это норм. даже в подкасте пятиминутки сказал это. но с тех пор на работе мы перестали использовать трейты вообще и я поменял своё мнение полностью в сторону того, что трейты не нужны.
но разберём этот кейс. допустим, мы решиил юзать messenger и контракт MessageRecordingEntityInterface будет использоваться на агрегатах. агрегат — это всегда кастом, потому что это часть уникальной бизнес-логики твоего проекта. контракт агрегата — это порождаемые им события. в этом смысле это его единственная ответственность — превратить команды в события. поэтому трейт нафиг, на базе этого интерфейса делаем абстрактный класс Aggregate (на стороне проекта, не в Symfony) и от него экстендим все агрегаты.
а в идеале как у @desper1989 в service-bus — аннотация на методе, из котрого можно забрать события. тогда и интерфейс не нужен никакой.
и на тот момент я считал, что трейт в библиотеке для примера реализации интерфейса — это норм. даже в подкасте пятиминутки сказал это. но с тех пор на работе мы перестали использовать трейты вообще и я поменял своё мнение полностью в сторону того, что трейты не нужны.
но разберём этот кейс. допустим, мы решиил юзать messenger и контракт MessageRecordingEntityInterface будет использоваться на агрегатах. агрегат — это всегда кастом, потому что это часть уникальной бизнес-логики твоего проекта. контракт агрегата — это порождаемые им события. в этом смысле это его единственная ответственность — превратить команды в события. поэтому трейт нафиг, на базе этого интерфейса делаем абстрактный класс Aggregate (на стороне проекта, не в Symfony) и от него экстендим все агрегаты.
а в идеале как у @desper1989 в service-bus — аннотация на методе, из котрого можно забрать события. тогда и интерфейс не нужен никакой.
M
Мне вообще пофиг, зачем их придумывали в пхп. Я лишь сказал, где, по-моему, их оправдано использовать.
Надо тогда искать случаи когда нужно множественное наследование
A
Надо тогда искать случаи когда нужно множественное наследование
Семантически это не является множественным наследованием.
Это реализация нескольких интерфейсов.
Это реализация нескольких интерфейсов.
ВУ
наследование — это зло, а множественное наследование — это множественное зло))
MM
Семантически это не является множественным наследованием.
Это реализация нескольких интерфейсов.
Это реализация нескольких интерфейсов.
Это даже не реализация нескольких интерфейсов. Это совпадение)
A
Это даже не реализация нескольких интерфейсов. Это совпадение)
?
MM
Ибо твой трейт про интерфейс ничего не знает
AT
наследование — это зло, а множественное наследование — это множественное зло))
ты же сам только что абстрактный класс предлагал)
M
Семантически это не является множественным наследованием.
Это реализация нескольких интерфейсов.
Это реализация нескольких интерфейсов.
Трейт + интерфейс это наследование, получается
A
Ибо твой трейт про интерфейс ничего не знает
Я говорил про случай, почему нельзя заменит interface + trait на абстрактный класс.
MM
я не скрываю, у меня есть такой PR в messenger: https://github.com/symfony/symfony/pull/34310/files#diff-83948907a24dc6a7916f694811a00ce1R19
и на тот момент я считал, что трейт в библиотеке для примера реализации интерфейса — это норм. даже в подкасте пятиминутки сказал это. но с тех пор на работе мы перестали использовать трейты вообще и я поменял своё мнение полностью в сторону того, что трейты не нужны.
но разберём этот кейс. допустим, мы решиил юзать messenger и контракт MessageRecordingEntityInterface будет использоваться на агрегатах. агрегат — это всегда кастом, потому что это часть уникальной бизнес-логики твоего проекта. контракт агрегата — это порождаемые им события. в этом смысле это его единственная ответственность — превратить команды в события. поэтому трейт нафиг, на базе этого интерфейса делаем абстрактный класс Aggregate (на стороне проекта, не в Symfony) и от него экстендим все агрегаты.
а в идеале как у @desper1989 в service-bus — аннотация на методе, из котрого можно забрать события. тогда и интерфейс не нужен никакой.
и на тот момент я считал, что трейт в библиотеке для примера реализации интерфейса — это норм. даже в подкасте пятиминутки сказал это. но с тех пор на работе мы перестали использовать трейты вообще и я поменял своё мнение полностью в сторону того, что трейты не нужны.
но разберём этот кейс. допустим, мы решиил юзать messenger и контракт MessageRecordingEntityInterface будет использоваться на агрегатах. агрегат — это всегда кастом, потому что это часть уникальной бизнес-логики твоего проекта. контракт агрегата — это порождаемые им события. в этом смысле это его единственная ответственность — превратить команды в события. поэтому трейт нафиг, на базе этого интерфейса делаем абстрактный класс Aggregate (на стороне проекта, не в Symfony) и от него экстендим все агрегаты.
а в идеале как у @desper1989 в service-bus — аннотация на методе, из котрого можно забрать события. тогда и интерфейс не нужен никакой.
У меня в аннотации обработчика можно прям залогать в каком хочешь виде
A
Трейт + интерфейс это наследование, получается
Имхо нет. У тебя нет класса родителя. И инстанса родителя ты же не можешь создать.
DD
Каждую секунду непонятные запросы на сайт. Что делать?
M
Имхо нет. У тебя нет класса родителя. И инстанса родителя ты же не можешь создать.
Интерфейс это и есть абстрактный класс